Re: [Lcd4linux-devel] plugin_wifi ?

[Martin H. <ma...@he...>]

Hi Xavier,

> - the first is parsing /proc/net/wireless (which exists for both 2.4 and
> 2.6) as /proc/net/dev, there are all the informations (unlike
> /proc/net/dev which shows only a few info).
This is an option - especially if one needs a plugin quickly (since it 
should be the easiest to implement).

> - another way is using ioctl : in fact there's no direct ioctl for
> wireless extensions, the stats are merged with "generic" stats (see
> include/linux/netdevice.h and include/net/iw_handler.h), works with all
> kernels (the new API is from 2002), but it handles too the 'normal' eth
> devices, so why not calling this plugin_net and delete plugin_netdev ?
Well, I'd favour this solution (using ioctl calls), but I would't rush 
into replacing something that works (plugin_netdev).
At first glance, trying to handle wireless devices (which supply 
additional data, which in turn is why there's need for a wifi-plugin to 
begin with) together with traditional network devices could make the 
code pretty ugly fast.

Lets get the wireless stuff taken care of first, and then see how we can 
merge traditional network devices and wireless devices.

> - the last way which won't please to Martin : all statistics ('normal' +
> wireless extensions) are exported in
> /sys/class/net/$interface_name/statistics, so we can access them
> easilly, just as plugin_i2c_sensors does ! But as you may guess, sysfs
> is only on 2.6.
Which IMHO pretty much rules out that option. I guess it will be a while 
until the majority of people will be using 2.6 (to my knowledge, there's 
only one distro that comes with 2.6 at this moment) - and even when 2.6 
becomes more common - I fail to see why a userspace app like lcd4linux 
would have to rely on the latest available kernel. If you feel like it, 
make it a configure option, if you want to get really fancy, detect 
which parsing routine to use at run-time, just like Michael does for the 
busy-waiting routine (or go ahead and code the wifi plugin for 2.6, and 
I'll code a 2.4 plugin for the rest of us).

> Now my point of view: the last two ways overpower plugin_netdev which
> can be removed then, and the plugin would be called plugin_net instead
> of plugin_wifi. But then, which one to use ? Using sysfs would be very
> easy and I can write the plugin in about 2hours from plugin_i2c_sensors,
If you do, please don't make that plugin "scream" like the i2c plugin, 
if it doesn't find its "/sys/whatever" directory. It is slightly 
annoying to have a plugin (that's not even referenced in the config) 
give errors on the command line, even when everything in the config is 
perfectly right.

> but some people will complain about their old, deprecated, outdated,
> superseeded, ..., 2.4 kernel not being supported :/ 
Indeed - not to speak of the people using the even older, even more 
deprecated, even more outdated, even more superseeded 2.2 (or dare I say 
2.0? I don't know if lcd4linux will run on a 2.0 kernel, but I'm 
guessing it should at least run on 2.2). What it comes down to for me is 
this: I don't see why some userspace app should dictate which kernel a 
person uses - especially not if there are perfectly fine ways of getting 
the same result without adding a dependency to kernel 2.6. But that's 
just me.

> We may in that case
> keep plugin_netdev and write rapidly a plugin_net_wireless which parses
> /proc/net/wireless (easilly writen too) so they can delay once more the
> migration to the best kernel ever released ( until 2.8 is out :D )
I think everybody on this list has understood by now that you are a big 
fan of 2.6 - so, if you want to write a "2.6 only" plugin, feel free to 
do so. But be assured - you won't make _me_ change to 2.6 any time soon 
;-) I may set up a test box some day to see if all the apps I need still 
work under 2.6, but for now, I'm happy to have a system that simply 
works (giving me time to work on other things - lcd4linux, for example - 
instead of playing with my linux installation).

> The best solution would be ioctl, but I don't know how to do this, and I
> don't know if it's worth the price to do this manner. If you know ioctl
> and wants to dig this way, just raise your hand :)
<Raises hand>
I'll take care of it. I can't say when (I unfortunately had to get some 
"real" work done this weekend (as in, "stuff one gets paid for"), but 
I'll try to put something together by next weekend.
</Raises hand>

Martin