Date: Sat, 17 Dec 94 18:13:00 MST From: terry@cs.weber.edu (Terry Lambert) To: joerg_wunsch@uriah.sax.de Cc: hackers@freebsd.org Subject: LKMs: limits to utility Message-ID: <9412180113.AA26706@cs.weber.edu> In-Reply-To: <199412161744.SAA00693@julia.tcd-dresden.de>; from "J Wunsch" at Dec 16, 94 6:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> | > | Just a thought : would trying to put the sound cards drivers as different > | lkms a bad idea instead of getting the kernel much bigger ? > > Now that everybody's speaking of LKM's, is there any documentation > available outside? I want to caution against the "I have a hammer, now everything's a nail" approach to the use of LKMs. Not that this is what I think you are suggesting, but that's where the current track seems headed. Specifically, LKMs as they are currently written are useful for: 1) Loading/Unloading kernel parts during developement to save reboot time. This assumes the module, when loaded, does not result in a kernel panic. 2) Boot-time loading of drivers that are never unloaded. They are *not* useful for general load/probe/fail_probe/unload. This is because there is no distinction between high, medium, and low persistance uses of kernel memory. The probe wants to be low persistance. This implies that the probe is either a sperate file or a seperate code segment in a single coff or elf file containing the rest of the module runtime. The modules themselves want to be either medium (demand loaded and developer loaded) or high (boot time loaded, device access time demand loaded). Current kernel memory management assume high persistance objects are loaded at boot time (the kernel itself) or closely thereafter. In a developement environement, you can afford the fragmentation of kernel memory that loading and unloading without collapsing the memory pools will cause, but this is not acceptable in a production system. I believe that the following *must* be done before everything ends up being modularized: 1) The linking must be against a kernel symbol list that is maintained apart from the kernel image itself. Currently there is a problem with module interdependency based on the link order and the resulting object file when the modules are linked against the kernel symbol table. This can not be resolved such that non-interdependent but time order previously linked modules can be unloaded without needing to reverse the load order. 2) As part of this, ideally, symbol resoloution would take place in the kernel itself (the module being loaded with vn_lookup() followed by vn_read's of the module data). Currently the module is pushed from user space into kernel space 512 bytes at a time after: i) The module is linked once against the kernel symbol table with a relocation offset of 0 to get a relocated object. ii) The resulting object is checked for size. iii) Contiguous memory aligned on a page boundry sufficient to contain the module is allocated and the kernel allocation address is passed back. This memory need only be contiguous i the kernel address space and not physically contiguous. iv) The module is relinked again against the kernel symbol table with a relocation offset equal to the start of the contiguous memory segment. This is all vastly more time consuming and error-prone than it needs to be. Pushing the symbol resoloution into the kernel will also allow the auto-export of symbols to the kernel symbol list. For instance, the exporting of symbols by an IP module for use by both a UDP and a TCP module. 3) At *least* "high/low" persistance pools must be established for kernel memory objects. I'd suggest halving the kernel virtual address space and allocating the low persistance stuff following the boundry and the high persistance stuff prior to the boundry (or vice versa -- I really don't care about the implementation details). There needs to be a mapping mechanism that allows "promotion" of low persistance obcts to be high persistance objects. This resolves the "probe" problem. If the device probes as being there, the module containing it is promoted. It should also be noted that as it stands, the LKM system was never intended for general use this way. It was an expedient hack by me to server the dual purpose of allowing me to load execution classes when I was doing initial work on share libraries in late 92/early 93 and to support the console working groups ability to load, among other things, emulation modules. With that in mind, my feelings would not be hurt by going back and reconsidering the entire design -- in fact, I'd recommend it. Regards, Terry Lambert terry@cs.weber.edu --- 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?9412180113.AA26706>