Date: Thu, 20 Mar 1997 11:14:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, bde@zeta.org.au, dgy@rtd.com, hackers@freebsd.org, helbig@MX.BA-Stuttgart.De Subject: Re: wd driver questions Message-ID: <199703201814.LAA13973@phaeton.artisoft.com> In-Reply-To: <199703200258.NAA00691@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Mar 20, 97 01:28:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> That's the one. There's also quite a lot of code whose behaviour depends > on various other options, but it would be practical in the short term > to just compile several times with the sensible combinations of the > various options and produce different modules. (I am thinking here > fe. of NFS_NOSERVER) The NFS_NOSERVER code changes the way the lease VOP's operate, not because the code should be condition, but because the code is badly integrated. The registration of lease management mechanisms should take place for all VFS consumers, not just NFS. This is a generic issue with not being able to register a set of event callback entry points for a module. The *real* problem here is that the NFS server wants to register event handlers, but the server and the client code are in the same module space. This is really a source organization issue. I could see a number of useful events that a VFS consumer at the system call level would want to register. For instance, directory modification events would probably be useful for a file browser application to monitor. In any case, no matter how you slice it, the NFS_NOSERVER is an exception because of implementation, not because it should be, so it isn't a good example. The DEBUG case is a better example, but even you say it should be per module. 8-). > > If you > > localize the "#if DEBUG" as "#if DEBUG_SUBSYSTEM", and create a > > depedency for the subsystem (by linking it to a single object before > > linking it to the kernel) than that should go away as well, or at > > least become sufficiently comparmentalized that you don't have the > > structures changing out from under you when some modules are compiled > > with the conditional and some are compiled without. > > Debugging should always have been on a per-module basis; having a single > kernelwide "DEBUG" define is clumsy. However 'debug subsystem' implies > always-present debug hooks, which can be expensive. I don't like that > much. Not a "subsystem for debugging", but "debugging for subsystem SUBSYSTEM". For instance, a VM object's relationship to other VM objects, and a process structure object's relationship to other process structure objects, should be encapsulated in the subsystem containing it. This means that I can, for example, change the size of the process structure without changing the ability of another subsystem to deal with the exported contents interface. In other words, the data in a proc structure not used by the proc structure code itself is invariant over debug. If you were a C++ geek, you would call the per subsystem debug data "private" (or "protected"). > > Specifically, I'd like to see options for kernel resource management > > handled via linker-set agregated data structures, highed bidder in the > > set wins (or better, agregate wins). This would let me provide minimal > > per-module resource requirements on a per-module basis, and still let me > > override by commiting an addition 'n' resources. Big win; for instance > > mbuf counts for big server sites, max subprocess counts for big user > > sites, etc.. > > Most of that would be better handled (as implied by Doug R.) by a > persistent attribute store (that R word) and dynamic allocation. I can't > see myself loading a module with nothing but 1024 mbufs in its BSS 8) Can you see linking one into a kernel? 8-). The problem with a registry is that it is not module local; to agregate two or more sets of objects into one larger single set requires that you imply counting methods, etc.. > > If you can read the blocks, and the load was sparse, you can fill in > > the sparse pieces. > > You are still not listening 8); I have just said "when you discover you > need the blocks, you can no longer read them because your load source > has gone." This is an issue for the period from when control is > transferred to the loaded kernel from the linker until a filesystem is > mounted, and thus all the code that could possibly be required over > that interval must be present. Heh. You aren't listening to me... you don't get rid of the boot-loader code. If you don't get rid of it, you can still use it. It's like the BIOS based boot being able to use the INT 13 redirector supplied by OnTrack, when you boot from an OnTrack drive. As long as you don't override it, it's still there. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703201814.LAA13973>