Date: Mon, 31 Mar 1997 11:10:35 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Terry Lambert <terry@lambert.org> Cc: current@freebsd.org Subject: Re: A new Kernel Module System Message-ID: <Pine.BSF.3.95q.970331102908.534G-100000@kipper.nlsystems.com> In-Reply-To: <199703302045.NAA08427@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 30 Mar 1997, Terry Lambert wrote: > > SYSINIT() is an image-global link-time configuration mechanism. It > must be implemented on top of something other than linker sets for > this to be an achievable goal. Since this was one of the design > considerations for SYSINIT(), this should be relatively trivial to > do. Once this is one, the SYSINIT() becomes an actual function > call reference, not a linker set reference, and the conditional > compilation issues for static vs. dynamic modules simply go away. The linker set for a dynamically loaded module would be local to the object file containing the module. Look at the implementation of C++ constructors in userland shared libraries. When the shlib is linked, the linker sets are aggregated. When it is loaded, the linker calls init code in the lib which uses the set. SYSINIT() from a loadable module would be similar. > > > Device instances (struct isa_device) will refer to their driver by > > name rather than by pointer. The name to driver mapping is > > performed and the device is probed and attached as normal. > > I'm not clear on why this abstraction is necessary or useful??? By keeping a separation between device instances (probed or otherwise) and device drivers, the driver does not need to be recompiled when the device configuration (irq or whatever) is changed. The driver should not depend on the individual resource requirements of a particular machine. > > > > Statically configured devices are placed in a table by config(8) > > and modules containing their drivers are added to the kernel > > Makefile. > > I would prefer that modules be build as seperate single object > files (potentially agregating multiple object files into one using > "ld -r"). > > A configuration is then simply a list of modules. > > I'm not sure if I like the idea of keeping a "config" around as > anything other than a set of linker directives (in the a,out case), > or as a vastly preferrable alternative, as input to an ELF section > librarian for an agregate kernel image. There has to be a clear distinction between device instances (isa_device in the current code) and device drivers (isa_driver). There can be many device instances using the same driver, each with its own private configuration data. The driver module itself must not embed any specific device configuration. This should be supplied to it, either by a user supplied configuration for legacy ISA devices or by a list generated at boot time by PnP, PCI, EISA etc. The configuration of a kernel is a list of modules plus a list of ISA device instances (assuming that ISA is the only bus which does not provide a complete list of attached devices). This list of device instances would be carefully ordered (exactly as it is today) to resulve probe difficulties. > > > Supporting static as well as dynamic modules makes the single > > module per object file paradigm of the existing LKM system > > difficult to maintain. A better approach is to separate the idea > > of a kernel module (a single kernel subsystem) from the idea of a > > kernel object file. The boot kernel should be thought of as > > simply a kernel object file which contains the modules that were > > configured statically. Dependencies between modules are also > > better treated as dependencies between object files (since they > > are typically linking dependencies). > > Is this ELF advocacy, or something else? > > The object module per LKM is still a valid approach (ld -r). Perhaps > you are considering a module that is set up as two distinct (and > reusable) components? If so, I would argue that allowing dependencies > and breaking it into two modules accomplishes much the same thing. The boot kernel is an example of a single kernel object which contains many modules. The act of aggregating (with ld -r) several objects into one also generates a single object containing many modules. > > > > The new system will use a kernel linker which can load object > > files into the kernel address space. After loading, sysinits from > > the new object file are run, allowing any modules contained > > therein to register themselves. The linker will keep track of > > which modules are contained in which object so that when a user > > unloads the object, the modules can be informed of the event. > > Other than name, there is no difference between this and the "_entry" > mechanism for identifying entry points, IMO. The big issue is, again, > the distinction between data (linker set) based and function call > based SYSINIT() mechanisms. My problem is that I want to be able to either load the modules individually or aggregate them into larger sets (or statically in the boot kernel). A single object file can only have a single entry point but can contain many SYSINITs. I want a function call based mechanism for initialisation to avoid embedding knowledge in the kernel linker of the many different linker sets in current use in the kernel. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.970331102908.534G-100000>