Date: Tue, 1 Apr 1997 14:21:46 +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.970401141031.305D-100000@kipper.nlsystems.com> In-Reply-To: <199703311732.KAA09669@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Mar 1997, Terry Lambert wrote: > > 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. > > I don't think this is the same thing, really. > > Consider that in order to use a dynamically linked shared library, > the symbol list must be imported into the executable that is bound > to the binary. You can't do this for a module which is dynamically > loaded; there is no symbol set within the kernel with knowledge of > the modules constructor symbol names, as there is when the symbols > are linked into the CTOR/DTOR list with a C++ shared library. That isn't quite what I am getting at here. What I mean is that the *implementation* of global ctors/dtors in a.out shlibs is by the use of linker sets. The linker set is aggregated together when the shlib is linker; on load time, the loader calls a single entry point for the shlib which deals with the constructors. In C++ at least, it is perfectly possible to have a shlib which has no exported symbols at all other than the ctor entry point. It can still perform useful work through the ctors. > > > > 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. > > Ah, I understand. It's to allow external manipulation of device data. > > Say I have an interface named "ed0" and I need variable numbers of > parameters to make it work? For instance PCMCIA vs. non-PCMCIA vs. > PnP ISA vs. real PnP PCI. Exactly. For legacy ISA devices which can't be reliably detected, probe hints are supplied by config(8). For PnP ISA devices, probe hints are generated by the pnp scan. > > The idea is sound, but perhaps it needs to be nearly as parametric > as PnP itself? That reminds me, I must read the PnP spec.. > But shouldn't device instantiation within a driver be handled by the > probe code coming true? Is this just for static configuration of > devices without invoking a probe? Yes. The device lists from config(8) are only needed to provide a list of hints on what to probe for. -- 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.970401141031.305D-100000>