Messages in this thread | | | Date | Mon, 25 Mar 2002 13:19:56 -0500 | From | christophe barbé <> | Subject | Re: [PATCH] 3c59x and resume |
| |
On Mon, Mar 25, 2002 at 10:01:33AM -0800, Greg KH wrote: > On Sun, Mar 24, 2002 at 09:25:45AM -0500, christophe barbé wrote: > > On Sun, Mar 24, 2002 at 12:07:29AM -0800, Greg KH wrote: > > > On Sat, Mar 23, 2002 at 05:44:33PM -0500, christophe barbé wrote: > > > > With the 'everything is module' and 'everything is hotplug' approach in > > > > mind (which is a appealing way and IMHO this is the way we are going), > > > > I see two part for this problem: > > > > > > > > . Persistence after plug out/plug in > > > > > > > > . Persistence after suspend/resume > > > > > > > > The first one is a userland problem. The card identification could be > > > > based on the MAC address (for NICs at least, in the case of cardbus the > > > > bus position has no real signification). This should then be the > > > > responsibility of the userspace tool (hotplug) to indicate the correct > > > > option for this card. The problem is when the module is already loaded, > > > > the userspace tool has no way to indicate this option. > > > > > > Untrue. See > > > http://www.kroah.com/linux/hotplug/ols_2001_hotplug_talk/html/mgp00014.html > > > for a 6 line version of /sbin/hotplug that always assigns the same > > > "ethX" value to the same MAC address. I think the patch to nameif has > > > gone in to support this, but I'm not sure. > > > > Untrue what ? The persistence after plug out/in ? > > No, the sentence, "The problem is when the module is already loaded..." > /sbin/hotplug gets called when the network device is started up, it > doesn't only get called before the module is loaded.
Ok I understand that but hotplug has no way to influence the way the device is treated by the driver. The only way I can see is via the /proc interface, but at least it is not possible with this driver.
> > The problem here is not to give the same interface to a given NIC. The > > problem is to give the same options to a given NIC. But a solution can > > simply be to set the option from hotplug using the proc interface. The > > 3c59x doesn't support that for wol but that can be changed. > > Understood.
So do you agree that something is missing here ?
> > > > And why is there a limitation of only 8 devices? Why not do what all > > > USB drivers do, and just create the structure that you need to use at > > > probe() time, and destroy it at remove() time? > > > > This is an implementation issue which is not really important. It comes > > from Donald Becker. Your dynamic structure doesn't solve the problem > > 'which options for which cards', does it ? > > No, but it solves the problem, "only 8 devices max", and "what to do > when a card is removed and then plugged back in." Both seems like good > things to fix in the driver :)
I have not checked the module loading code but is it possible to define for an option a vector with an undefined size ? Or do you consider that all devices use the same option ? (the vortex driver is only limited to 8 cards for the options passed by modutils)
Could you point me to a specific usb driver ?
How is solved the "what to do when a card is removed and then plugged back in." problem ? By keeping the entry for further use ?
Christophe
> thanks, > > greg k-h
-- Christophe Barbé <christophe.barbe@ufies.org> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E
There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann [unhandled content-type:application/pgp-signature] | |