[patch] wireless network support

[Joe Shaw]

On Wed, 2004-05-26 at 11:41 -0400, Pat Suwalski wrote:
> If need be, I can devote time to see how different cards/drivers behave 
> with this. Depending on the driver different events will be generated. I 
> have easy access to about 15 different wireless cards. Yes, I do lots 
> with wireless cards.

That'd be great.  All I have are orinoco cards, and the current driver
in 2.6.5 doesn't have scanning, so I had to build them by hand.  Someone
tried an atheros driver too and that worked, I hear.

> The downside is this dependency that really not all distros support.

Hmm, what distros ship iwlib as part of their pcmcia support?  And
shouldn't the startup scripts act sanely if they're started and the
machine doesn't have PCMCIA? :)  On SUSE iwlib is in wireless-tools, so
it shouldn't be a problem.  Dunno about other distros right now.

> Something I suggest you look into is James Willcox's (snorp's) libiw 
> patch. He reshuffled some of the functionality from the iwtools 
> themselves into the library. He submitted the patch upstream, but I 
> don't know what the current status is. This patch allowed the library to 
> do more (an example off the top of my head is base station scanning). 
> There might have been interesting things for HAL in there as well.

Fortunately I talked to him yesterday since he was in town. :)  The
maintainer has never replied to his patches, which is always
encouraging.  But essentially he just made the code so that there was a
struct (similar to APInfo in my code) so that apps wouldn't have to do
all the messy parsing.  So basically my code is similar to his, only his
was in the library itself.  It won't really change the deps or anything
like that.  The other problem with his is that scanning requires root
for most drivers, and the applet doesn't run as root.  hald does.

> Do you consider wireless to be ethernet? If so, it's a pretty loose 
> definition. It's also the reason why (at this point) the minority of 
> wireless cards stick with the ethX device name.

Hmm, there seems to be a lot of dispute about this. :)  I'm the first to
admit that I don't really know.

> One more property which would be nice to see is what type of card it is. 
> PCMCIA/Cardbus cards are the most popular, but minipci is quickly taking 
> over. [...] Some program may want that feature to know if it can be 
> ejected or whatever.

Don't we have a general "info.removable" or "info.hotpluggable" property
or something like that?  That might make sense to have.  Problem with
PCMCIA in Linux is that it's not well exposed through sysfs, so there's
no way for us to know how a class device (ie, /sys/class/net/eth1)
associates with a system device (ie, /sys/devices/pcietc.).  So with
just the eth1 info, we don't know if it's PCMCIA or what.  This probably
can't be fixed in the short term.

> Keep in mind that the variety of card formats will limit the number of 
> displayable properties, and will definitely introduce error. Wireless 
> cards are the flakiest thing in Linux now that devfs is deprecated.

Yeah, I don't know how to avoid this except for app authors to realize
that many of these properties would be optional.

Thanks,
Joe


_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal