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

William W. Ferrell wwf@frontierdev.com
Thu, 22 Mar 2001 16:00:24 -0700

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

--- dglaude@netbrain.be's mailer spewed these beefy chunks ---
> Hey, this use to be a quiet list, you remeber.
> Now I cannot not follow everyone ideas. ;-)

Yeah, but I think I like the active list more than the dead, "I wonder
if anyone's still even *thinking* about LCDproc or not" list :)

> So as far as I remember from mail I have seen so far.
>  * "Named pipe": David is the only on to like it. ;-)

I think more than just David who likes that idea. I'm sold, if you'll
recall :) It's just a matter of supporting Windoze with it.

>  * William and other have a portable way to do loadable module.

Mebbe. :)

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

=2E..and I'm the senior sysadmin at an all-Solaris shop, and am given a
rather wide berth to experiment even with production systems (we're a
development shop :), so I can test what we come up with and can probably
help develop too.=20

Although I'm not about to fork over the $600 Sun wants for their bloody
compiler. GCC suits me just fine :)

>  * Windows is always a problem, but it as been done before...

Hehehehe :)

>  * Kernel space, we don't like that but for some driver why not?

Er, 'cause it's different for every platform, and may not be possible
under 'doze without buying expensive M$ software to develop it :)

> Maybe for Windows we don't need the server side...

Or we fork the Windoze LCDd and make it use a TCP/IP socket for
server<->driver communication.

> The only think I don't fully grasp is this story of network connection:

(I haven't read the quoted response below yet; my mail is sorted
most-recent first and I'm answering 'em that way. Sorry if I repeat
something someone's already said...opinions are welcome if anyone can
suggest even cooler ways to handle mailing lists in mutt :)

> >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 =3D 3
> or
> Client + LCDd =3D 2
> David GLAUDE

Dammit. This is a hard decision.

I want to keep LCDd as simple as possible, and making it keep track of
half a dozen *additional* network connections just to talk to drivers
isn't going to help us reach that goal. But it may be the only useful
way to do things in Windoze.

Or we drop support entirely for Windoze. Or we just bite the bullet and
make LCDd work that way on all platforms (LCDd + driver processes +
client processes).

I hate my flip-floppy brain. Now as I write this it's telling me "hey,
stupid, that 3-process thing isn't such a bad idea!" I suppose we're not
just *adding* "one socket per device", but we're also *removing* "one
dynamic load per device" as well. Dynamic loading is different on the
various platforms we're discussing; sockets aren't, even in 'doze.

Perhaps this is just my inexperience talking. :)

William W. Ferrell, Senior System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202   1.303.223.0564

Public key available:
  gpg --keyserver certserver.pgp.com --recv-key 7478FC7A

Trying to get an education here is like trying to get a drink from a fire h=

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org


Content-Type: text/plain; charset=

To unsubscribe from this list send a blank message to