after each SYSINIT() macro invocation. This makes a number of
lightweight C parsers much happier with the FreeBSD kernel
source, including cflow's prcc and lxr.
MFC after: 1 month
Discussed with: imp, rink
future:
rename ttyopen() -> tty_open() and ttyclose() -> tty_close().
We need the ttyopen() and ttyclose() for the new generic cdevsw
functions for tty devices in order to have consistent naming.
respectively. Most of the longs should probably have been
u_longs, but this changes is just to prevent warnings about
casts between pointers and integers of different sizes, not
to fix poorly chosen types.
Distribute all but the most fundamental malloc types. This time I also
remembered the trick to making things static: Put "static" in front of
them.
A couple of finer points by: bde
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
civilised manner than panicing. This only happens as a result of another
state botch somewhere else, eg: from a tty driver calling putc or b_to_q
on a closed device. Apparently, it's also been implicated in a panic
with a status (^T) event on ptys.
This change should pretty well be in it's final form now.
non-fatal. I've make it return an appropriate error to the caller instead
of panic()ing.
Handling an error condition is inherently more friendly than exploding
the kernel.. :-) The new behavior is a little closer to traditional
clists, potentially making porting a little simpler.
Suggested by: bde (many months ago, I've been using this for a while..)
TTYHOG = 1024 bytes, 10 cblocks were reserved. This was thought to
provide 10 * CBSIZE = 1080 bytes of buffering, but if the head pointer
is at the end of a cblock, then it only provides 1 + 9 * CBSIZE = 973
bytes of buffering. This caused serious data loss for ptys because the
flow control is deterministic and requires at least TTYHOG bytes of
buffering. For ttys, if input flow control is used then there is
usually enough slop in the high watermark to avoid problems, and if
input flow control isn't used then a limit of 973 is not much different
from a limit of 1024.
Add prototypes.
Continue cleaning up new init stuff.
Submitted by: terry (terry lambert)
This is a composite of 3 patch sets submitted by terry.
they are:
New low-level init code that supports loadbal modules better
some cleanups in the namei code to help terry in 16-bit character support
some changes to the mount-root code to make it a little more
modular..
NOTE: mounting root off cdrom or NFS MIGHT be broken as I haven't been able
to test those cases..
certainly mounting root of disk still works just fine..
mfs should work but is untested. (tomorrows task)
The low level init stuff includes a total rewrite of init_main.c
to make it possible for new modules to have an init phase by simply
adding an entry to a TEXT_SET (or is it DATA_SET) list. thus a new module can
be added to the kernel without editing any other files other than the
'files' file.
operation of each clist. Limit the growth of each clist. Clists
can only grow larger than the reserved minimum if there are free
cblocks in a shared pool. The size of this pool is now fixed
(this could be improved). The reserved and maximum sizes are more
carefully allocated for slip and ppp, depending on the mtu. A maximum
MTU of 16384 is now enforced for ppp.
cycles. While waiting there I added a lot of the extra ()'s I have, (I have
never used LISP to any extent). So I compiled the kernel with -Wall and
shut up a lot of "suggest you add ()'s", removed a bunch of unused var's
and added a couple of declarations here and there. Having a lap-top is
highly recommended. My kernel still runs, yell at me if you kernel breaks.
