Date: Sat, 22 Mar 1997 13:42:24 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dfr@render.com 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: Kernel configuration futures (Was Re: wd driver questions) Message-ID: <199703222042.NAA19437@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.95.970322173301.333B-100000@kipper.nlsystems.com> from "Doug Rabson" at Mar 22, 97 05:56:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Yes... the difference is, I want to be able to pull a module from > > an already linked kernel, and to do that, I have to deagregate the > > linker set data agregated from that module. 8-(. > > I think that in the long run, this might be useful but only marginally. > The only modules which should be included in the static kernel are ones > which will be used. Including dozens of drivers in the kernel only to > ditch them later is just wasteful. Say we include a VM86()-based INT 13 disk driver that will, by definition, work with all disk controllers that DOS, Windows, and NT can use. Because it is INT 13 based, it is single-threaded, and can not do overlapped I/O. Now say we have an Adaptec 2940 controller. We want to replace the universal, but inferior performing, driver with an Adaptec 2940 specific driver. How can we do this? Well, if we can't deagregate the INT 13 driver because of the way it is hooked in, then we can't do it. We have to rebuild the kernel. > It also seems to me that to be able to discard a module from the static > kernel, you would need to pad all its sections to VM pages so that you can > re-use the pages. This also sounds wasteful. You need to pad it's sections *in memory* to VM pages. If you physically pad them, then it will be wasteful of 0-511 bytes (assuming a frag size of 512 bytes and a sparse image file) and be a little faster. But you don't have to do it. That's why Sun supports VOP_GETPAGE and VOP_PUTPAGE. > > Novell? TCP/IPX... 8-) 8-). > > That is the other way around, TCP without IP. Is that possible? I > thought the normal streaming protocol for IPX was SPX or something. I > know very little about Novell.. The normal one is SPX. Their internet proxy server runs over TCP/IPX and gates to TCP/IP. > The link/load should definately be in the kernel. I firmly believe that > the cost of the runtime symbol tables is well worth the gain of allowing > inter-module dependancies, and kernel-initiated module loads. Well, that's two of us. 8-). > > > See my other reply. I think the restrictions of running in the loader > > > (size and non-interrupt-driven i/o) make the use of a full-blown > > > filesystem impractical. > > > > Depends on how well defined the VFS bottom end becomes. I think the > > current state of affairs in this regard is abysmal... there are some > > 120 or so kernel interfaces required to support the full Heidemann > > framework. This is an unacceptable bottom end. > > Any changes to this area are going to take far too long. I want to get > something practical and small working fairly quickly. Bells and whistles > can come later. That still lets us have a set of non-VFS-based vn_* file I/O routines. The only difference is whether the vnode from one of these is allowed to persist over the changeover to the other vn_* routines. vn_* is a small enough spanning set of functions for an agegate interface that can operate in both real and protected mode with little overhead. If the real mode code keeps the path on vn_open's, they can be reopened in protected mode without losing. Actually sharing the code can come later, but sharing the interface ought to be considered up front. > > You don't need a registry for this (as above). If you don't like the > > "metaprobe" idea, rather than scanning the registry, it could look > > for an ELF segment "device data" in the files before it loaded them; > > either way, a real registry is not really necessary. > > This would work I guess. It still means scanning all the drivers, opening > the files etc. How does it get a complete list of drivers? One way might > be to force all pci driver modules to be installed in a single directory > (e.g. /lkm/pci/*.o or whatever). Even if the device id information is > embedded in a section of the ELF file, I still think it is better to > compile a single index file by scanning the drivers at install time. Or delete non-essential drivers at install time (move them to another directory, etc., instead of really deleting them). Do you really want to have to build a registry before you build the rest of the code? 8-). > The install floppy's MFS does take up space in RAM. For the install disk, > it still makes sense to statically include as many drivers as possible. > The GENERIC kernel that gets installed can be *much* simpler. Well, I'd say "driver disk now, fallback drivers later" to handle this one... that way you include "support for as many drivers as possible" without actually including "as many drivers as possible". THe additional disk would be a nice annoyance to promote fallback driver developement. 8-). 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?199703222042.NAA19437>