[lcdproc] "named pipe" is different from/dev/lcdkernel code. :-)]

[David Glaude]

Hey, this use to be a quiet list, you remeber.

Now I cannot not follow everyone ideas. ;-)

So as far as I remember from mail I have seen so far.
 * "Named pipe": David is the only on to like it. ;-)
 * William and other have a portable way to do loadable module.
 * We have a portable way to get unix stats (cpu/mem/...).
 * We have a new target os: OS/2 but need someone with it. ;-)
 * We have solaris and BSD addict that can try on their platform.
 * Windows is always a problem, but it as been done before...
 * Kernel space, we don't like that but for some driver why not?
(Add your stuff here or fixme)

Maybe for Windows we don't need the server side...
Just a client that get stats and TCP tell us.

The only think I don't fully grasp is this story of network connection:
>From: Harald Klein
>To: William W. Ferrell
>Cc: lcdproc@lists.omnipotent.net
>Sent: 22/03/01 18:08
>Subject: Re: [lcdproc] [Fwd: [lcdproc] "named pipe" is different
>from/dev/lcdkernel code. :-)]
>
>don't like #IFDEFS, if windows isnt able to handle pipes i vote for tcp
>sockets.
>dynamic loadables should be fine, too, but the network approach supports
>remote displays kinda X.
>
>hari

Do you want to replace my named pipe idea with a TCP connection?
Is it:
Client --[TCP]-> LCDd --[TCP]-> Driver --[Phy]-> Hardware ?

I ask that because previously on the list I have been talking
about Serial LCD connected to a terminal server (TCP->Serial).
And this was possible if we replace every write to the serial to
a write to a TCP connection.

How many process do we want?
Client + LCDd + Driver = 3
or
Client + LCDd = 2

David GLAUDE


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