Re: co-existance of pppd and mgetty ?

Johan =?iso-8859-1?Q?Myr=E9en?= (jem@vistacom.fi)
Sat, 11 May 1996 17:53:59 +0300 (EET DST)


On Fri, 10 May 1996, Bill Hogan wrote:

> jm> On the contrary, since pppd gets it right, I think it is good pppd
> hides that information, making it harder to break it.
>
> jm> You are not supposed to change the lock directory name.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I disagree.
>
> Hiding information only causes people to waste time looking for
> it.

I still think hiding this piece of information in pppd is OK, because pppd
gets it RIGHT (according to the FSSTND). The lock directory is not
something you are supposed to change at will, because it is a shared
resource. Many independent programs rely on its location. A developer who
writes a program that needs a lock on a serial port should be able to rely
on the correct system-wide location of the lock directory.

We all agree that there is definitely a need for a a standardized
location for the lock directory, don't we? Thanks to the effort of the
FSSTND team, we HAVE such a path, and it is /var/lock. We should be
grateful for this, and not make life harder for ourselves.

> As you said, "The easiest way is to make /var/spool/uucp a link to
> ..." the lock directory used by `pppd' (and for which suggestion I
> thank you) but that would be hard to do without knowing the name of
> the lock directory used by `pppd'.

It is not a question of what lock directory pppd uses, the question is:
what is the standardized lock directory _EVERY_ program is supposed to use
for locking shared resources. There is no reason for pppd to advertise
that it uses /var/lock, "but you can change that by changing the
definition here and there", because that would break pppd and all other
programs using serial port lock files.

The location of the lock directory is not something the end user
(including somebody who compiles a software package) should need to know.
The lock directory IS supposed to be known by the developers, but this
does not always seem to be true. A Unix program is not ported correctly to
Linux if it uses a lock directory path that is not /var/lock.

> Personally, I prefer to see generic file names such as `LOCKFILE'
> coded into programs, leaving me free to decide where I want the actual
> information to go.

What's wrong with a standardised location? You'd have to change every
program to use a different lock directory. It's like renaming /bin/sh to
/bin/hs and change the first line of every shell script on the system to
#!/bin/hs.

> E.g., if I have a program `prog' that sends output to PROGFILE
> then I can use a simple wrapper like
>
> export PROGFILE=/home/gonzo/prog.log
> /usr/local/bin/prog

Yes, but (if I understand you correctly) the difference is that PROGFILE
is a variable private to your program. If this idea is applied to the lock
file location, it would mean we'd need a standard (adopted by every
program) that says the environment LOCKDIR points to the lock file
directory. The FSSTND (the only standard we have for this in the Linux
world) does not implement it this way. Instead it says /var/lock is THE
directory to use.

> This way, the programmer does not have to worry about OS-specific
> details and can therefore concentrate more on the algorithm being
> implemented.

I'm afraid a programmer WILL have to deal with OS-specific details in
cases like this. At least if he wants to write programs to be used by end
users.

Johan Myreen
jem@iki.fi