Date: Fri, 5 Jun 1998 22:09:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eivind@yes.no (Eivind Eklund) Cc: tlambert@primenet.com, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... Message-ID: <199806052209.PAA06934@usr08.primenet.com> In-Reply-To: <19980605000726.58908@follo.net> from "Eivind Eklund" at Jun 5, 98 00:07:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > The big issue here is *only* the boot blocks, since aggregation
> > is a matter of "what is default in the kernel" and "what objects
> > are linked into the 'installed' subdirectory from the 'available'
> > subdirectory".
>
> This is just plain wrong. If you want to get rid of config, you got
> to move the functions it presently handle somewhere else, and
> eliminate the blocks to using pure aggregation one by one.
I remember your list; I think we should seperate "code presence" from
"conditional compilation", and eliminate all "conditional compilation".
I'll respond to your conditional compilation issues on a case-by-case
basis:
* The use of 'UNION' in vfs_syscalls.c
This is there because the auio.uio_resid is not being
properly adjusted by the UNIONFS VOP_READDIR when the
upper vnode's data is exhausted.
The repeat entry elimination in readdir(3) is also
broken -- getdirentries(2) is capable of returning
duplicate entries, but nowhere is this noted.
It is the job of the unionfs to take care of this problem
on behalf of callers to it.
The unionfs is broken.
Dike the code out of here, and put it in (in "#if 0"
form) in the miscfs/union/union_vops.c in the union_readdir
code.
* The use of COMPAT_43 at all
Remove this entirely. Make the code always be there.
Comment before and after it, if you care.
* The dependency of the Linux module on COMPAT_43
with COMPAT_43 always there, this goes away.
* The way 1/3 of the the kernel is dependent on 'INET'
This is wrong. I count the net/if_*.c files, the net/route.c
file, debug code in netipx/netns, and a bunch of stupid
ethernet drivers that care about the protocols that are going
to be run on the card for bogus organizational reasons.
This has more to do with the lack of a DDI/DKI for address
family registration than anything else.
Since I've written code to do this twice before, it's
probably someone else's turn, unless you can guarantee
a commit this time.
* The way the BOOTP options are used all through the kernel
Whoever is using this should add the necessary SYSINIT to
make it start working again, once it is impossible to define
BOOTP at compile time via "config".
The VFS root volume handling is problematic because the
fact that it's pure idiocy to disctinguish root mounts
from non-root mounts in the first place.
I have railed on this before, but lack of support for the
idea has foiled integration of my soloution.
The basic idea would be to seperate the mount procedure into
the FS specific code, which only made a mount structure entry,
and the mapping into the FS hierarchy and NFS volume export,
which would all be in common code. This would necessitate
a VFS_MOUNTEDON VFSOP to set the "last mounted on" for FS's
that supported this information (like FFS); it would be a
NULL op for those that didn't (like CD9660, MSDOSFS, etc.).
* Some other way of setting the panic reboot time
Default it large, and let it be sysctl'ed down if the
machine can boot that far.
* Move SPX_HACK to a sysctl, including creating proper infrastructure
around it (or possible just decide that we're going to throw this
options away - I don't know if anybody use it)
This is the correct thing to do. Remove the ability to
use it by removing the ability to set the variable, and
let someone who needs it convert the conditional code
into a sysctl.
* The way 'QUOTA' change things in all the filesystems
Either default it on (#define QUOTA 1), or do the same as
for the SPX_HACK: leave it for whoever uses it. If it's
defaulted on, leave the reduction in kernel size to whoever
uses it.
The correct implementation will make a QUOTAFS stacking
layer, such that all FS's can use quotas, and no conditional
compilation is ever required.
I have seperated these out for special treatment:
* The existance of 'maxusers' and all the constants that depend on it
* The use of defines to set options for the AHC driver
* The use of defines to shift the tuner in the brooktree driver
* The use of defines instead of variables to control kernel PPP
These are all things which can be manifested on or off or
to a particular value, and then the people who care about
them can put in the work to make them runtime configurable
(sysctl or whatever).
The major issue with these is that the code that depends on
them may not take kindly to runtime changes of value.
It may be worthwhile to make these -D's in the Makefile
for the kernel, until such time as someone cares to resolve
them. I can give you a set of Makefile rules for dealing
with dependencies on things like ".maxusers=*", if you
don't want to trivially code them up yourself.
> I gave you a list of about 10 things that have to be fixed before we
> can get rid of config (or something else that basically do the
> function of config, including separate compilation with differing
> defines).
The issue is one of conditional compilation within a compilation unit,
and not selection of compilation units, I think. I think this is a
resolvable problem, which can be made to put the work on the people
who care (personally, I care about QUOTA, so I'd probably end up
making work for myself on that one, unless it was defaulted on, and
you made work for people who wanted smaller kernels, instead of for
me).
> If you have some other way of handling those issues, that's fine - but
> they have to be handled! And believe me, I'd like to have a system
> that didn't need config, too - I just don't believe it can happen
> without somebody putting down a lot of work towards that end,
> ruthlessly eliminating obstacle by obstacle.
Is the above ruthless enough for a first pass? If you will sign off
on it, I'll code it up.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806052209.PAA06934>