[Fwd: Vgetty question]

Gert Doering (gert@greenie.muc.de)
Wed, 23 Jun 1999 19:01:19 +0200


Hi,

On Wed, Jun 23, 1999 at 06:35:23PM +0000, Vandoorselaere Yoann wrote:
> > Actually I think this is a good design.  You have low level functions
> > (tio.o, locks.o, logfile.o - they could be in a library, but I didn't do
> > that for portability), mid level functions (libvoice.a) and high level
> > programs (vgetty, vm).  How would you do this differently?
> For portability ?
> Please say me what a library have to do with portability !!!

There are systems out there where it is *hard* to do create a library
(ancient 3B1, SCO, others) - and mgetty runs on all those systems.  This
is the main reason why the *mgetty* parts (locks.o etc.) are not in
something like a "libserial.a" or such.  Portability, and maybe some
laziness on my part.

The voice/ stuff is a lot less portable than the basic mgetty+sendfax
stuff anyway, and thus we can use more "modern features" in this part 
- and that's why Marc did libvoice.a.

> > > Why didn't you use standard file locking ?
> > What do you mean by this?  The only place mgetty/vgetty does "file
> > locking" is for the serial port, and there is only one "standard" way to
> > do that - using LCK..ttySx files, and this is what locks.o is doing.
> flock can do it all.

No, it can't.

  - flock doesn't give you the process ID of the process holding the lock
    (this is important for logging and for mgetty's callback signalling).

  - flock doesn't work with all other programs abiding to the "serial
    port locking convention" (LCK..ttySx), like cu, minicom, kermit,
    seyon, hylafax, etc - and this is the main reason why you HAVE to
    do it that way: it is a standard, and ALL programs have to obey 
    this standard, otherwise it's useless.

  - LCK..ttySx locking is, up to a certain extent, cooperative.  This
    is *good*, if done right, because you get much flexibility that
    you can't get with forced locking via flock or via (that's the
    other proposal that creeps up regularily) kernel enforced locking.