Using the "best available" driver

Wed Dec 7 15:00:43 EST 2005

On Wed, Dec 07, 2005 at 01:42:53PM +0100, Dominik Brodowski wrote:
> Hi,
> 
> On Mon, Dec 05, 2005 at 03:40:18PM -0800, Jean Tourrilhes wrote:
> > 	Now, I want to start brainstorming about the next step : how
> > do we offer this functionality in a friendly form to our users.
> 
> Well, on a modularized kernel, the /etc/modprobe.conf blacklisting method
> seems to be quite user friendly, even though it requires a reboot.

	A blacklist is clearly not good enough. I already told you that.
	Example :
	The Orinoco driver support both Orinoco, Symbol and Prism2 cards
	The HostAP driver support only Prism2 cards. It has more
features than the Orinoco driver, by is twice as large (footprint).
	I have 2 Pcmcia slot, I insert both a Orinoco and a Prism2
cards (yes, I can really do that on my PC). I usually want the Orinoco
card to be driver by the Orinoco driver, and the Prism2 card driven
with the HostAP driver. For debugging the Orinoco driver, sometimes I
want to bind the Orinoco driver to the Orinoco driver.
	Obviously, on my Gumstix, I want to use the Orinoco driver
with my CF card.
	As you can see, this kind of stuff is clearly not doable with
a dumb blacklist. And it's also not doable with a module
removal/reinsertion.

	And the reboot is also clearly not acceptable. I don't mind
ejecting the card, but a reboot sucks on my P3 500 MHz.

	From my box :
-------------------------------------
# cardctl ident
Socket 0:
  product info: "Lucent Technologies", "WaveLAN/IEEE", "Version 01.01", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)
Socket 1:
  no product info available
Socket 2:
  product info: "Instant Wireless ", " Network PC CARD", "Version 01.02", ""
  manfid: 0x0156, 0x0002
  function: 6 (network)
-------------------------------------
# lsmod
Module                  Size  Used by
orinoco_cs             16424  0 
orinoco                42324  1 orinoco_cs
hermes                  7712  2 orinoco_cs,orinoco
hostap_cs              62904  7 
hostap                116644  1 hostap_cs
ieee80211_crypt         5760  1 hostap
prism54                55880  0 
pcmcia                 34220  8 orinoco_cs,hostap_cs
firmware_class          9216  2 prism54,pcmcia
yenta_socket           26380  4 
i82365                 20528  7 
rsrc_nonstatic         13280  2 yenta_socket,i82365
pcmcia_core            38356  4 pcmcia,yenta_socket,i82365,rsrc_nonstatic
irda                  198748  0 
crc_ccitt               2816  1 irda
hp100                  20864  0 
pcnet32                28516  0 
mii                     5824  1 pcnet32
crc32                   4928  2 pcmcia,pcnet32
-------------------------------------
	(First is a genuine Orinoco card, second is a Prism2 card).

	Note that with kernel 2.6.15, the above setup does not work
with cardmgr, while it was working before (2.4.X). Whichever driver
was loaded first try to manage both card, which most often does not
work (HostAP can not drive an Orinoco card).

	Please acknowledge the people are trying to use your code in
way that may not make sense to you, but it's not because we are being
pedantic, it's because we *NEED* it. Thanks.

> > 	The sysfs commands are fine, but they are rather obscure, and
> > are not persistent. What would be nice is to have a list associating
> > cards IDs with the driver needed. Not an axhaustive list, but just the
> > user override. Then, each time the card is loaded, the hotplug script
> > would do the necessary magic to get the right driver binded (and
> > potentially unload the uncessary driver).
> 
> I'd consider this to be too complicated -- we'd need yet another table of
> IDs of drivers and devices. Having them in one place where it matters is
> good.

	Whatever we need, we need, it's as simple as that. I don't
advocate a full list in user space, that would be plain stupid, but
just a list of overrides, which for most people would be empty.

> The actual removal will take a few months more, I suspect, but that's the
> plan yes. And with the easy /etc/modprobe.conf blacklisting method as well
> as the "rmmod X && sleep 1 && modprobe Y" being available immediately after
> the IOCTL is gone I don't think that this is a blocking issue. Do you agree?

	Well, because it's already broken in 2.6.15, this issue
obviously does not block the removal of the ioctl. So, I fully agree
with you. I'm already not very happy that the new Pcmcia stack does no
longer support desktop PCI-Pcmcia bridge properly, so I'll just add
that to my list.
	With respect to the removal of the ioctl, you may want to
contact the various people supporting Pcmcia in the various distro and
asking them about how far they are supporting the new utilities. They
are the people that are going to be impacted the most.

http://packages.debian.org/unstable/source/pcmcia-cs
http://packages.gentoo.org/search/?sstring=pcmcia

http://rpmseek.com/rpm/pcmciautils-007-1.i386.html?hl=com&cs=pcmcia:PN:0:0:0:0:2139560
http://rpmseek.com/rpm/pcmciautils-010-2mdk.i586.html?hl=com&cs=pcmcia:PN:0:0:0:0:2372037
http://rpmseek.com/rpm/pcmcia-3.2.8-7.i586.html?hl=com&cs=pcmcia:PN:0:0:0:0:2103097

	Hmm... A first glance, 3 out of 5. Not bad, but could be better ;-)

> Thanks,
> 	Dominik

	Have fun...

	Jean