From owner-freebsd-hackers Mon Apr 17 00:56:19 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA10365 for hackers-outgoing; Mon, 17 Apr 1995 00:56:19 -0700 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA10352 for ; Mon, 17 Apr 1995 00:56:10 -0700 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.8/8.6.6) id CAA02183; Mon, 17 Apr 1995 02:53:09 -0400 From: "House of Debuggin'" Message-Id: <199504170653.CAA02183@skynet.ctr.columbia.edu> Subject: Re: support for Xircom PCMCIA Ethernet adapters? To: terry@cs.weber.edu (Terry Lambert) Date: Mon, 17 Apr 1995 02:53:06 -0400 (EDT) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <9504170502.AA06646@cs.weber.edu> from "Terry Lambert" at Apr 16, 95 11:02:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5281 Sender: hackers-owner@FreeBSD.org Precedence: bulk They say this Terry Lambert person was kidding when he wrote: > > > Is there support for the PCMCIA Xircom Creditcard Ethernet Adapter IIPS > > > in FreeBSD-2.0, or is anyone working on implementing it? > > > > I've read somewhere that Xircom has a very restrictive copyright > > policy. You'll perhaps be outta luck getting documentation. > > If someone is interested in disassembling Xircom's code and documenting > their registers and proper programming procative from the code, then > posting that information, this would allow someone else to write a > driver without problems. Somehow this reminds me of an old Steve Martin routine. ("Yes, if you follow these two simple little steps, you can have a million dollars and *never* pay taxes. First, get a million dollars. Second...") > On the other hand, I have suggested many times that the loadable > kernel modules should have their loader code in the kernel, and > this is one example why: to enable demand loading in a general > case seperate from consideration of the symbol tables to enable > the loading od Novell ODI drivers for servers. These are protected > mode driver that exist for nearly all ethernet and many token ring > and other odd cards. Ah, now you've done it! Novell ODI drivers be damned: you've brought up the subject of loadable kernel modules right when I'm in the middle of hacking on kern_lkm.c! :) I've noticed that there are now loadable modules for PPP, SLIP and the tunnel driver. I've further noticed that none of these drivers play by the rules: to use them, you modload them with an entry point of pppattach (or slattach, or tunattach), which can cause major havoc since pppattach() has no LKM-specific modifications in it at all. This is to say that no 'private' section is created when the module is loaded. This leads to a panic the moment someone runs modstat and the kernel tries to look for private.lkm_any->lkm_name, which doesn't exist. The major problem I'm having is that I can't find a way to detect such bastardized modules prior to actually calling their entry points. Basically, I've figured out that if private.lkm_any == NULL after the entry call has happened, the module is screwey, and special steps must be taken (I create a dummy lkm_any structure to pacify modstat and mark the module type as LM_UNKNOWN (I check for LM_UNKNOWN later if modunload is called and refuse to unload the module becasuse doing so without crashing the system is next to impossible)). The trouble is that I need to prevent the user from loading the same rogue module twice (with if_ppp_mod.o, loading twice yields two ppp0's and two ppp1's, which is just too damn strange). But by the time I know that I have a bad module, it's too late to do anything about it. To wit: - user loads a module (modload -e pppattach if_ppp_mod.o) - LKM_READY comes up, and we go to call the entry function - call to entry returns with private.lkm_any == NULL -- module is bogus! - fix up the lkm_any structure to avoid modstat/modunload panic - see if we already have a module loaded with the same name - no duplicates: we can continue - user is a twit; loads module again - LKM_READY comes up, go call entry again - private.lkm_any == NULL again -- another bogus module! - fix up the lkm_any structure to avoid modstat/modunload panic - see if we already have a module loaded with the same name - it's a duplicate! we have to unload it! - [Here is where we are hosed: assuming this is the PPP module, calling the entry point of the module has already caused pppattach() to wire in a second set of PPP devices. Now that this has happened, there's no way to cleanly un-wire them again because the PPP module has no unload() function.] - attempt to remove the module: lkmunreserve() its pages - at some point, the kernel goes looking for the now-defunct duplicate PPP module and whammo! we're toast. It's sort of a 'chicken and the egg' problem: I have to detect the bad module and discard it before I call its entry point, but I have to call its entry point before I can detect and discard it. Now, I know what you're probably going to say: fix the stupid modules so they can properly un-install themselves. True, that would fix these particular modules, but it won't squash the bugs in the kernel's LKM code that lead to the panic. So, o master of loadable modules: is there a way I can spot these buggers before digging myself into a hole, or am I SOL? > That UnixWare does it proves it is possible. Kurt Mahon has hinted > that he might be able to get some of his code for this released. *sigh* > Terry Lambert > terry@cs.weber.edu > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~~~ FreeBSD 2.1.0-Development #0: Tue Mar 14 11:11:25 EST 1995 ~~~~~~~~~