[lcdproc] Why not use named pipe like LIRC? (v0.5 suggestion)

[David Glaude]

>> To do that would involve getting into kernel-space territory. While not a
>> problem from the info side on Linux, (I'm currently writing a device
>> driver), it does mean we'd have to do the same for each other OS. Also,
as
>> most of the devices are themselves accessed through /dev entries, (ttyS0,
>> ...), it would be quite tricky to write stuff into /dev/lcd, and then
>> route that back out into user-space to then dump it into the appropriate
>> device.
>
>Please, don't do that. A device is a piece of hardware, the kernel provides
>special access to. We *do* have a device, we do not need another one
>doing almost the same. That *really* *really* belongs to user space! (As
>it is right now).

Of course NOONE wants to go into the kernel for our little LCD. (???)
And as long as there is a way to do it in user space, let's do it.

I might have another option that is unix minded and might help split
the driver side from the server side. Also support standalone client.

I am talking about 'named(?) pipe':
 a pipe(|) in filename space someone is reading, the driver
 and someone is writing, lcdproc server/standalone client.

I have seen this in use within LIRC and IRMAN.
Basicaly one piece of code is a deamon, hardware specific that
translate receaved IR into something readable in a standard way.
The same apply to us except that it is for writing.

ASCII Drawing:

Physical Matrix Orbital screen
 ^
 | [Serial cable]
 |
/dev/xxx
 ^
 | [Standard write on the device]
 |
MO driver
 ^
 | [Named pipe]
 |
LCDproc (offer widget/multiplex client over the net)
 ^
 | [TCP connection]
 |
Client (CPU usage/disk usage/...)

Rem: This is almost like what as been done to emulate MO LCD on X by someone
sometime ago.

That way the development of hardware specific driver is not LCDproc problem
anymore.
The work done to standardize LCD API can be used without LCDproc for
standalone client.
LCDproc can concentrate on widget, client multiplexing, security, ...
Also we can offer hot-swapping/dynamic-adding of LCD by asking LCDproc to
re-read the config file.

WARNING:
	* I don't know how to handel the keypad of Matrix Orbital.
	* I don't know what is the best API but it must fit inside a stream
of byte with no return value.
	* LCDd better be ready when driver are there or other will reuse the
driver without LCDd. ;-)
	* I don't know if Windows is having somethin similar to named pipe
that we could use. :^)

>Maybe you Linux guys should make a decision, whether BSD should be kept
>supported or not. If not, I'll branch from my patched 0.4pre9, make it
>stable, remove al Linuxisms and keep it as it is, as I'm quite
>satisfied with the way it works and the amount of functionality.

Tom, if you can stay with us and keep some common code, this will benefice
everybody.
What are our Linuxisms?
Are they inside the client or the driver or the LCDd code?

I think we should keep the client (lcdproc) and the server LCDd two separate
issue.
I think portability issue are inside the driver (//port access)
and inside the client (reading CPU usage, ...).

The multiplexing/widget part of LCDd should be quiet portable.

What do you think?

David GLAUDE


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net