devfs_link.9: modified man page to reflect source code
devfs_add_devsw.9: replaced by devfs_add_devswf.9
devfs_add_devswf.9: proper function for adding devices to DEVFS
discussionn when they were initially added some time ago.
These programs are not needed before nfs is up and running to possibly
mount /usr so they dont need to be static and on the root fs.
word: "zilch"). I guess the only way to get people try and comment on
these kind of things is to shove it down their throat.... ;)
Anyway, here's a set of changes required for auto-generation of READMEs
in ports directories. Necessary changes and additions of templates
to the ports tree will follow shortly.
Eventually I'll commit all the generated READMEs to the tree, but that
will be in the rather distant future. For now, I encourage anyone
with a -current systam and a matching ports tree to do a "make readmes"
at the top level and see what they get.
Next step will be to add pkg/{COMMENT,DESCR} to all the categories.
- Use rpcgen to generate the unmodified boilerplate code rather than
having it in the repository.
- Eliminate the conflicting function names by changing them to their
"natural" rpcgen generated names
Changed DEVFS structure devfs_token so that adding the devices is
a simple matter of a 4 line for loop versus 16 lines of code
Reviewed by: julian@freebsd.org
looks rather ugly.
Also slightly adopt the contents to the results of a discussion that
took place in -core some months ago. We couldn't agree on everything,
but some of the previous sentiments were rather outdated.
easy setup of default quotas for a range of uids. Usage:
edquota -p protouser startuid-enduid
E.g.
edquota -p mpp 10000-19999
Will duplicate the quota limints for user mpp for uids 10000 - 19999.
The uids in question do not have to currently exist in /etc/passwd.
which has been in the tree for a much longer time.
Sorry for the multiple commits and I know I shouldn't be doing this but
my hamster tells me to be orthogonal...("hey Phoenix, do you think
I should call it LOCALBASE?" "squeak" "ok, if you say so").
counterpart to X11BASE (default "/usr/X11R6").
Now PREFIX is set to ${X11BASE} or ${LOCAL_PREFIX} depending on
whether USE_IMAKE or USE_X11 is set or not.
This enables us to refer to non-X ports from X ports using
${LOCAL_PREFIX}, thus removing most of the remaining "/usr/local"s
from the ports tree.
This will also allow the system administrator to move the whole
"local" tree to somewhere else, without affecting X ports. (Of course
not all ports are necessarily happy with that, but we're working on
it.)
Based on: an idea that came up while I was watching a football game
several months ago ("hey, maybe I can move that sideline
without disturbing the other!")
. Replace my NIH-suffering code to detect the number of lines on
the terminal by the curses variable LINES.
. Fix the selection code for countries with more than one screenful
of locations. The very few people living in America/US/Pacific
now won't be charged for Indiana any longer... :)
. Removed the gross code that copied over the timezone file to
/etc/localtime, and create a symlink now instead.
Always delay using one inb(0x84) after each i/o in rtcin() - don't
do this conditional on the bogus option DUMMY_NOPS not being defined.
If you want an optionally slightly faster rtcin() again, then inline
it and use a better named option or sysctl variable. It only needs
to be fast in rtcintr().
aesthetics of using the 4.4 queue macros without paying undo space or time
in scenartios where a singly-linked list works fine.
From queue.h:
/*
* A singly-linked list is headed by a single forward pointer. The elements
* are singly linked for minimum space and pointer manipulation overhead at
* the expense of O(n) removal for arbitrary elements. New elements can be
* added to the list after an existing element or at the head of the list.
* Elements being removed from the head of the list should use the explicit
* macro for this purpose for optimum efficiency. A singly-linked list may
* only be traversed in the forward direction. Singly-linked lists are ideal
* for applications with large datasets and few or no removals or for
* implementing a LIFO queue.
*
* A singly-linked tail queue is headed by a pair of pointers, one to the
* head of the list and the other to the tail of the list. The elements are
* singly linked for minimum space and pointer manipulation overhead at the
* expense of O(n) removal for arbitrary elements. New elements can be added
* to the list after an existing element, at the head of the list, or at the
* end of the list. Elements being removed from the head of the tail queue
* should use the explicit macro for this purpose for optimum efficiency.
* A singly-linked tail queue may only be traversed in the forward direction.
* Singly-linked tail queues are ideal for applications with large datasets
* and few or no removals or for implementing a FIFO queue.
*/
