Date: Mon, 17 Apr 95 10:46:34 MDT From: terry@cs.weber.edu (Terry Lambert) To: wpaul@skynet.ctr.columbia.edu (House of Debuggin) Cc: freebsd-hackers@FreeBSD.org Subject: Re: support for Xircom PCMCIA Ethernet adapters? Message-ID: <9504171646.AA08223@cs.weber.edu> In-Reply-To: <199504170653.CAA02183@skynet.ctr.columbia.edu> from "House of Debuggin" at Apr 17, 95 02:53:06 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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...")
No, it's more like "clean room coding is possible, but free software
projects typically do not engage in the practice because it requires
two or more people to work together on something". 8-).
One could make the same argument about WINE engineering clean-rooming
code out of Windows itself instead of coming up with half soloutions.
The ability to clean room is relative to the energy one is willing to
expend. With people like Xircom, Adaptec, Diamond, and multiport
board vendors hiding their interfaces this way, it's clear that the
only thing this really does is create an artificial barrier to entry
for someone who wants to duplicate the hardware, and that barrier is
only as high as the willingness to expend the effort to openly reverse
engineer their code without the vendors cooperation.
Simple problem, obvious soloution.
[ ... on to loadable modules ... ]
> 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)).
This is one of the reasons I keep suggesting that the symbol resoloution
ought to be done in the kernel instead of outside it in the ld program.
> 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.
This is not the problem. The problem is not preventing a module that
does not register itself from being loaded twice. The problem is that
you are not immediately unloading that module with loud complaints
about it having not registered itself.
> - 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!
FORCE UNLOAD OF MODULE WITH ERROR MESSAGE "module has no identification".
> - 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
FORCE UNLOAD OF MODULE WITH ERROR MESSAGE "module has no identification".
> - 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
NO SUCH MODULE (it wasn't permitted to load).
> - 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.
Assuming relocation in the kernel, there are two options. The first
is to allow multiple symbols in the module to be imported by the kernel.
The current limitation on this is on the basis of the a.out format that
the module is stored in allowing only a single symbol to be resolved.
The second approach would be to ammend the routines available to the
module from the single multiplexed entry point to include a seperate
registration entry point from the "attach" entry point so you can
insert a validation step into the load/register-init, changing it into
load/register/validate/init.
> 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.
No; this is not a soloution, simply because it is possible to have modules
that you can never unload. Consider a console driver or a disk controller
driver that replaces a more primitive version (a fallback version) of the
code that was only sufficient to get the machine to the point it could
boot. For instance, a SCSI driver that gets loaded to replace a VM86()
BIOS call based driver.
It is likely that the new driver would establish state in common with
the controller card from which the priginal state is impossible to
recover. Consider the microcode download to Adaptec SCSI controllers.
> 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?
Changing the load mechanism itsel is the only way -- I think Garrett (who
has hacked on that code more recently than me, I assure you) would agree,
although I don't know if he still disagrees with the idea of putting the
loader in the kernel itself or not. 8-).
Terry Lambert
terry@cs.weber.edu
---
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?9504171646.AA08223>