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