[patch] wireless network support

[Pat Suwalski]

David Zeuthen wrote:
<snip>
> Yay, I think this is quite nice. One could wonder whether this is
> stretching what the HAL should do; my take on that is that it makes
> good sense to do this; I mean, it's the same thing we do for wired
> networks with the property net.ethernet.link. I'm curious what other
> people think?

The quiet one shall speak.

> My only concern is that might cause a storm of D-BUS signal emissions
> and callouts; Kay talked about adding attributes to properties so
> perhaps one day we could say something like

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.

<snip>
>>The main strike against this patch is that it adds iwlib as a
>>dependency.  We could either continue with that or import part (or all)
>>of the code into hal.  Unfortunately the interfaces between the kernel
>>and user space are so tightly intertwined that I don't think we could
>>have a smaller, separate implementation.
> 
> I think it would be rather unconstructive to duplicate code for the
> sake of removing dependencies (and iwlib isn't really a policital
> target like some other deps), so can't we just make this a
> compile-time option? If distribution vendors are supporting wireless
> ethernet they sure have iwlib available anyway.

This is the iffiest thing in this whole arrangement. On one hand, it 
basically covers getting information from every card, even the 
NDIS-wrappered ones.

The downside is this dependency that really not all distros support. I 
know it's for the better, but it would be great if this was optional. 
Distros will naturally group libiw with pcmcia and other laptop things, 
so this would force a bit of reshuffling on their part. Not a big deal, 
worst case scenario is that pcmcia would attempt to start at bootup, 
meaning it would pull in isapnp from the kernel, meaning that some 
systems would break because that's what the pnp modules do.

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.

> My only other comment is that the properties should be called
> net.ethernet.wireless instead of just net.wireless, since other
> wireless networking technologies may or may not exist.

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.

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. I have a minipci orinoco card, and it pretends to be PCMCIA 
(literally, cardctl interacts with it like pcmcia orinoco, lists it as a 
third slot). My current atheros card is a true minipci, and shows up 
under lspci. I also have a number of USB wireless 'cards'. This would be 
nice to show as a property, maybe. Perhaps net.wireless.pcmcia 
(true|false). Some program may want that feature to know if it can be 
ejected or whatever.

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.

I know, I know, I'm not terribly coherent today.

--Pat

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