Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!park.uvcc.edu!ns.novell.com!gateway.novell.com!thisbe!terry From: terry@thisbe.npd.Novell.COM (Terry Lambert) Subject: Re: WD Ethernet Card not found on warmboot Message-ID: <1992Aug24.174709.5431@gateway.novell.com> Sender: terry@thisbe (Terry Lambert) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <1992Aug19.165319.14767@doug.cae.wisc.edu> <714317431.111@eyrie.img.com.au> <1992Aug21.171828.14323@doug.cae.wisc.edu> <1992Aug24.085511.21092@autelca.ascom.ch> Date: Mon, 24 Aug 1992 17:47:09 GMT Lines: 71 In article <1992Aug24.085511.21092@autelca.ascom.ch>, nbladt@autelca.ascom.ch (Norbert Bladt) writes: |> dinda@cae.wisc.edu (Dinda Peter) writes: |> |> >In article <714317431.111@eyrie.img.com.au> athos@eyrie.img.com.au (David Burren) writes: |> >>I also have an Elite16 Combo (it's the 8013E with AUI, BNC, & UTP) and |> [ text about problems with WD-Ethernet board deleted. - NB |> |> >Every solution I've gotten so far is to "recompile the kernel." I |> >really wonder why Unix *still* doesn't have installable device drivers. |> Buy Solaris 2.0 and you will get it (perhaps, i.e. I've not seen it). SunOs from 4.1.0 has this ability. It's just not well documented (but then again try finding out what your frame buffer registers marked "reserved" do). The NeWSPrint software uses it by default. |> >Is there a fundamental reason why Unix hasn't/will not support this? |> No, because it will be done. However, if nobody really requests this, |> nobody will spend time and money to implement it, right ? I disagree. It isn't being done on 386BSD because the GNU linker can't handle linking an object (a driver) to an already linked object (/386bsd). I have ported my loadable kernel module package that I wrote for SVR4 to 386BSD, except for this problem. What has to be accomplished is to resolve references to kernel routines once at a known address and once at a relocation address. The process is fairly simple: 1) "Link" the driver.o against the kernel with a base relocation address of 0 to get it's size. 2) Make a call (ioctl) to a "driver" to allocate that much memory and return the start address. 3) "Link" the driver.o against the kernel with a base relocation address of the start address. 4) Make a call (ioctl) to the same "driver" to load the named file (the resulting "executable") at the start address. 5) Make a call (ioctl) to the same "driver" to cause the initialization routine to be run (thus modifying one of several possible kernel tables to include pointers to the loaded modules routines). For system calls, this blows some "nosys" system calls at a known offset in sysent. For drivers, it replaces "null" entries in the appropriate devswitch table. 6) Optionally, maintain load information so that the modiles can be unloaded. Obviously, this requires linker support, and possible compiler support so that base address relative jumps and offsets aren't used, in case page alignment of the code is different between 0 and the start address (thus corrupting the expected size. This can be ignored if one is willing to overallocate memory in the kernel. There are also some changes required to the kernel debugger if these are to be recognized. One of the big glamors of gcc 2.x is the ability to produce position independant code, which, with modification of the exec and base loader software and the changes to the linker for either load-time symbol resoloution or stub call through, buys us not only the ability to produce loadable kernel modules, but also buys us shared libraries for nearly free. Anyone care to "bell the cat" and do the compiler work? Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.