Date: Mon, 17 Apr 1995 02:53:06 -0400 (EDT) From: "House of Debuggin'" <wpaul@skynet.ctr.columbia.edu> To: terry@cs.weber.edu (Terry Lambert) Cc: freebsd-hackers@FreeBSD.org Subject: Re: support for Xircom PCMCIA Ethernet adapters? Message-ID: <199504170653.CAA02183@skynet.ctr.columbia.edu> In-Reply-To: <9504170502.AA06646@cs.weber.edu> from "Terry Lambert" at Apr 16, 95 11:02:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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 ~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504170653.CAA02183>