From owner-freebsd-current Fri Jun 5 15:10:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA26288 for freebsd-current-outgoing; Fri, 5 Jun 1998 15:10:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA26174 for ; Fri, 5 Jun 1998 15:10:01 -0700 (PDT) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA22584; Fri, 5 Jun 1998 15:09:57 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd022544; Fri Jun 5 15:09:52 1998 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id PAA06934; Fri, 5 Jun 1998 15:09:38 -0700 (MST) From: Terry Lambert Message-Id: <199806052209.PAA06934@usr08.primenet.com> Subject: Re: I see one major problem with DEVFS... To: eivind@yes.no (Eivind Eklund) Date: Fri, 5 Jun 1998 22:09:38 +0000 (GMT) Cc: tlambert@primenet.com, current@FreeBSD.ORG In-Reply-To: <19980605000726.58908@follo.net> from "Eivind Eklund" at Jun 5, 98 00:07:26 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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