[lcdproc] "named pipe" is different from/dev/lcdkernel code.
Thu, 22 Mar 2001 17:37:41 +0100
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
>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
>dynamic loadables should be fine, too, but the network approach supports
>remote displays kinda X.
Do you want to replace my named pipe idea with a TCP connection?
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
Client + LCDd = 2
To unsubscribe from this list send a blank message to