Re: [Lcd4linux-devel] plugin_mysql, to do list.

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

Hi Xavier,

>>My suggestion (and that's the way I understood Michael as well) is to 
>>use a "worker process/thread" for each plugin that will be slow/may 
>>block. Memory consumption is not so much an issue, since most of it will 
>>be marked as "shared" anyway, so memory usage on the box will only 
>>increase marginally.
> 
> Okay, I was misinformed about fork. Let's continue this way.
> But another question : for example eval needs the mail('unread') value,
> so calls a (hypothetical) mail() function in plugin_mail, which forks to
> retreive POP summary, and it takes, for example, 5 seconds, what does
> the eval do within this time ? I don't know what Michael wants on this
> issue.
I guess Michael has already answered that one. If eval waited for the 
fork to complete (and deliver the data), we'd still be doing things 
synchronously, and thus would have gained nothing.

To get around that problem with the first call failing - I guess we 
could get fancy and supply some kind of "callback" (which would get 
called when the data is available) - but to me it sounds like that would 
be overkill, considering we're only talking about the first call to that 
function that causes problems.

>>A syscall? Care to explain? All I know so far is that the wireless 
>>extensions API works via IOCTL calls - I never heard/read of syscalls 
>>for that in the past (maybe this is simply about a different definition 
>>of "syscall" - to me, a "syscall" is a function exported by the kernel - 
>>whereas an IOCTL call is a specific syscall, that takes specific 
>>parameters (and those parameters tell it what to do)).
> 
> I don't really know what is the difference, I've not been hacking IOCTL
>  since this week :), but read linux-2.6.4/include/net/iw_handler.h,
>  there are a bunch of explanations there for the new API.
Well, please don't use _too_ new features, since that would mean people 
still running the 2.4 kernel will be left out. I would prefer to stick 
to the API defined here
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
to avoid compatibility problems (I don't know - maybe that's exactly 
what's made its way into 2.6 - I haven't run 2.6 so far, and from the 
look of things, it may still be a while until I will - not because I 
think 2.6 is bad, just because I don't have the time to mess with my 
system just for the heck of it).

> If it's possible, I would prefer to call this [IOCTL|syscall] instead of
> parsing /proc/net/wireless, as it's funnier and more educative for me.
Absolutely - besides, it should be much more efficient and less error 
prone. The only drawback is that it will hit us if the API changes 
(which is unlikely though, since the API seems to be pretty stable).

>>So, you _are_ working on that (or did you just add it to your ToDo 
>>list)? Don't get me wrong - I just want to make sure we don't duplicate 
>>work (and still get a working wifi plugin in a timely manner). I've 
>>added plenty of things onto my ToDo list in the past (which I never 
>>completed), so I want to make sure :-)
> 
> I'll write this, but you may help me if you know [IOCTL|syscall] well,
> as I don't know either how to do :)
Sure, just let me know if you need help. Using IOCTL is pretty simple - 
it's all about finding which parameters to use (which one usually needs 
to pick from the source of the driver one is calling into) - just have a 
look at drv_generic_parport.c in lcd4linux to get an idea how it's done 
(really, there's not much to it). The only thing one needs to be careful 
about is to provide the right kind of pointer for the 3rd parameter - if 
the driver expects a pointer to an int, and you supply a pointer to a 
char, strange things will happen.

> Reading plugin_dvb.c, IOCTL are special adresses in a /dev node, while,
> as far as I understand wireless extensions have merged in
> linux/include/linux/netdevice.h, and "INET is implemented using the BSD
> Socket interface as the means of communication with the user level"
> Help ?!?!
Well, IOCTLs are done on a filehandle (and usually on the file-handle of 
a file in the /dev/ directory). That's the most common. The wireless 
extensions apparently require IOCTL calls to a socket - which apparently 
works just as well.

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.Extensions.html

(especially the section 5.2 IOCTL) has some info on how that works.

If I were writing the plugin, I'd probably start out with going through 
the source-code of the wireless tools (which obviously use the wireless 
extensions API themselves), to get a feel for how things work.

I hope that helps.

Martin

-- 
You think that's tough?  Try herding cats!