On Thu, Sep 01, 2005 at 02:13:21PM +0200, Jiri Benc wrote:
> On Wed, 31 Aug 2005 10:52:54 -0700, Jean Tourrilhes wrote:
> > I personally consider that a bug in ifplugd. For example, the
> > hp100 Ethernet driver will start media sensing only in the open()
> > call, which means that ifplugd won't work on the hp100 driver.
> > It would be trivial to fix ifplugd to open the device without
> > an IP configuration before doing media sensing. If the device doesn't
> > have an IP config, it won't be used by the networking
> > layer. Similarly, when ifplugd doesn't want anymore to use an
> > interface, it remove the IP address from it and leave it up.
>
> I thought this was done by not passing the -a parameter to ifplugd.
I have not used ifplugd, so I'm pretty clueless to what it
does. James was complaining that ifplugd require carrier sensing
before "ifconfig up" and that was the main root of his issues. If you
tell me that ifplugd can "ifconfig up" before carrier sensing, then we
can just use that and then everybody is happy.
Note that, as I've stated, this is not a wireless specific
issue (it can happen with Ethernet, and I expect some USB Ethernet
devices require firmware loading), so the solution should not be
wireless specific.
> > Anyway, it seems that ifplugd itself see media sensing has not
> > trivial and has many options to do media sensing, and had many changes
> > in that part, so they don't see that as totally clear and
> > straightforward.
>
> Because there is no common standard? Every driver should do this the
> same way.
Yeah, the Ethernet API are fluctuating, but at least the
Wireless API has always been well defined. The other part of the
reason is that carrier sensing doesn't always have the same meaning,
depending on technology.
> > Having the MAC address before open() is not mandatory. I
> > specifically designed ifrename with a *wide* variety of selectors, so
> > that user could address trivially cases where the device doesn't have
> > a MAC address at boot up, and the man page makes it clear that the MAC
> > address is not always present.
>
> But (at least part of) distributions recognize cards by MAC addresses.
> And I'm not sure there exists something better than MAC address to
> distinguish cards.
>
> > For example :
> > ----------------------------------------
> > ipw* driver ipw2100
> > ----------------------------------------
> > would work properly on your driver even if you don't read the
> > MAC address until open().
>
> And if you have two ipw2100 cards?
There can't be two ipw2100 in the same device, because laptops
only have a single mini-PCI slot. But yeah, it could happen for other
devices (prism54 comes to mind).
In the example above, they would be called ipw0 and ipw1,
which is already good enough for most users (the two interfaces offer
the same functionality, so are interchangeable). If you want to really
separate the two interfaces, you could do for example :
----------------------------------------
ipwfirst driver ipw2100 businfo 0000:02:05.0
ipwsecond driver ipw2100 businfo 0000:02:07.0
----------------------------------------
This is why ifrename is infinitely superior to all the
alternatives ;-) And if you have a neat idea for another interesting
selector, I'll add it to ifrename.
> > Correct, however the problem is not WE per say. We are not
> > going to change the networking scripts of all existing distribution to
> > add a specific call to associate wireless devices. And then change all
> > the existing wireless drivers.
>
> I'm not for specific call for association. But I don't think that the
> problem you described is really a problem - when the device is opened
> without performing association call, association can be requested
> automatically by ieee80211 layer before driver's open method is called.
Yep.
And let's not forget that you can always force an association
when the device is down with "iwconfig commit". But as I was saying
above, as the problem is not wireless specific, the solution should
not be wireless specific.
> It's about the problem with MAC address availability.
I would be worried of making everything too dependant on the
MAC address, as it is something that can be changed by the system or
the user via "ifconfig hw".
Most other OSes seems to identify devices by businfo. Of
course, in the past it was not possible with Linux, because before
2.6.X we did not have a unified bus model (and Pcmcia is only getting
there now).
I'm not sure identifying netdev by businfo is always the right
solution either. But, if we support both, I think we can please
eveybody...
> > There are patches on my web page adding Wireless Extensions
> > over RtNetlink, which seems exactly like what everybody is clamoring
> > about. They have been sent a couple of time to this mailing list. To
> > date, I've received *zero* feedback on those.
>
> We will take a look.
By the way, tell me which way you prefer for the stream macros
(see my other e-mail).
> Jiri Benc
Have fun...
Jean
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
