lcd4linux-devel

[Lcd4linux-devel] plugin_wifi ?

[Xavier V. <xav...@fr...>]

Hello list, especially Martin and Michael.

Let's continue our dicussion about plugin_wifi :
I see three solutions to the claim :

- 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).

- 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 ?

- 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.

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,
but some people will complain about their old, deprecated, outdated,
superseeded, ..., 2.4 kernel not being supported :/ 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 )

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 :)

Bye !
-- 
Xavier VELLO <xav...@fr...>

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

Re: [Lcd4linux-devel] plugin_wifi ?

[Xavier V. <xav...@fr...>]

Hello Michael, hello Martin, hello list !

> 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.
That's why I like the sysfs solution, as it provides all the  
 informations ioctl provides without getting hard to implement (open
  the file, copy a buffer, strtod and we are) but there's the backward
 compatibility problem.

> Lets get the wireless stuff taken care of first, and then see how we can 
> merge traditional network devices and wireless devices.
I'm downloaded the wireless-tools source and the source of my wifi card
driver for 2.6, I'll try to experiment ioctl a bit, then we'll decide
what to do

> > 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
Yes, I am :)
> - 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).
Okay, I won't dictate you to migrate to 2.6. But just read the next 4 lines:
2.4 hasn't been really stable until several monthes, but 2.6 is already
stable. Linus has understood the lesson with 2.4 and the 2.5 test phase
has been longer than ever. I use 2.6 since 2.6.2 and never had big
problems with it (just one: vmware didn't worked, but I didn't use it)

>  or go ahead and code the wifi plugin for 2.6, and I'll code a 2.4
>  plugin for the rest of us).
Maybe it would be the best solution if ioctl are too complicated. Each
would be quite easy to code (one based on plugin_netdev, the other based
on i2c_sensors) while the ioctl one would be quite hard to code, IMHO

> > 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>
Err... does somebody know if ioctl are _really_ faster than reading
procfs/sysfs ? I think ioctl imply (at least for this case) more memory
problems and uggly code.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] plugin_wifi ?

[Xavier V. <xav...@fr...>]

Helli Martin !

> > I use 2.6 since 2.6.2 and never had big
> > problems with it (just one: vmware didn't worked, but I didn't use it)
> Well, for me, vmware is one of the show-stoppers (I don't really want to 
> have to back to dual-booting or having another computer under my desk). 
> And please, lets not get into the "what do you need windows for? Linux 
> can do everything" discussion - lets just assume that there is a need 
> for me to run windows at home, even if I prefer Linux most of the time.
In fact, the old version I had didn't support 2.6, but new versions do
 (hopefully) support 2.6 ! But as I didn't use it anymore, I didn't
 searched for an upgrade on *mule :)

> >> or go ahead and code the wifi plugin for 2.6, and I'll code a 2.4
> >> plugin for the rest of us).
> > Maybe it would be the best solution if ioctl are too complicated. Each
> > would be quite easy to code (one based on plugin_netdev, the other based
> > on i2c_sensors) while the ioctl one would be quite hard to code, IMHO
> I don't really see why it would be terribly hard to code - but I haven't 
> had time to look at it in detail yet.
I digged into wireless-tools source, and here is what to do :
- open a socket : socket(AF_INEL, SOCK_DGRM, 0)
- check if the interface has wireless extensions (SIOCGIWNAME ioctl)
- get the statistics (SIOCGIWSTATS ioctl)
- handle the iw_statistics struct, which contains itself structs, and
parse the info.
It is easier than I expected.

> I'm not quite sure why it would imply more memory "problems" (I'm not 
> even sure what you're referring to actually - do you mean memory usage? 
> "memory problems" imply a bug to me).
It's both a little more memory usage, but moreover, manipulating
struct->struct->__u32 variables may get quite messy :/
I'll try to code a test.

Bye !
-- 
Xavier VELLO <xav...@fr...>

Re: [Lcd4linux-devel] plugin_wifi ?

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

Hi again,

> - 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 ?
Second thoughts - after looking at the kernel stuff (the other end of 
the IOCTL calls), I'd even say it's smart to keep those separated.
So far, I've been unable to locate _any_ location in the kernel, where 
one can get the the same device-stats (rx_bytes, tx_bytes and so on) via 
ioctl calls as one gets via parsing the output of /proc/net/dev.

If we keep things separate, it should keep things nice and simple:
* plugin_net_dev for printing traffic stats - afterall, displaying bytes 
sent/received is pretty much independant of the actual implementation of 
the device)
* plugin_wireless (or whatever name we decide to use), for extra info 
(like channel, operation mode, sensitivity, transmit power, link 
quality, signal level, noise level and so on). All of those are very 
"wifi-specific", so keeping this separate should help keep things 
compact, once we go to dynamic loading of plugins.


If, on the other hand, you've found a way to get the same info via ioctl 
calls as one can get from /proc/net/dev, please do tell me - I'd love to 
know a way to get around having to parse that potentially large string 
(one of my test boxes has 10 different interfaces in /proc/net/dev - not 
only physical ones, but also logical ones, for VPNs and stuff like that).

Martin

Re: [Lcd4linux-devel] plugin_wifi ?

[Michael R. <re...@eu...>]

Hi there,

I see no problem if the same information can be read from two different 
plugins. In fact, the plugin_ppp does exactly this: it returns CPS rate 
which is the same as the info from /proc/net/dev

As you already have seen, plugin_netdev won't be obsolete because not 
all the information passed here is available via ioctl()

as for the 2.4/2.6 discussion: lcd4linux should be as independant from 
the kernel as possible. There are some dependencies (e.g. the format of 
some files in /proc) but I always tried to autodetect the format and 
support as many formats=kernels as possible.

I have a 2.6 up and running here, but some very important subsystems 
(e.g. USB or VMware) fail at the moment... Thats why I go with 2.4.

The "main" kernel for lcd4linux is 2.4 , and probably will be for the 
next months.

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...