[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Speak now, or...



> From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
> Michael K. Johnson:
> > Not any more.  We've discussed this on the pam list already.  As we
> > agreed, a pamified login forks, execs, and waits.  Yes, it's not what
> > Unix has done since the beginning of time.  We do know that.  We are
> > now changing that.
> OK, so I'm speaking now.  I know I am a little conservative,
> but it worries me when we start changing the way things work
> in Unix unless it's really necessary.  We shouldn't create
> incompatibilities with the rest of the world (including Sun)
> without a very good reason.

When you initiate and terminate something - such as a session - it's in
theory best to do it from the same level.  I've long been mildly
annoyed that things set up in 'login' aren't cleared there.  Obviously,
the process at the "same level" as a Unix login, at logout, will either
be the shell or whatever program is set up as the "login shell" in the
passwd file.  This program hasn't - and shouldn't have - privileges to
do the appropriate cleanup; plus it will have lost a lot of the "state"
that's needed to know what the appropriate cleanup is.  Thus, we have
the 'init' program - one level higher [!] - being forced to clean up
after any of its children who happen to be 'login' processes.

I've lived with this because in V5, V6, V7, 32V, PWB I, System III,
System V, [234]BSD, processes were traditionally pretty expensive,
using up much of your 64 Kb / 1 Mb / 2 Mb / whatever.*  Nowadays you
can have 32 Mb on one SIMM in your PC.  Wow.  Of course, you also have
PCs with much less memory, and we shouldn't forget them.  However, now
we're in a much better position to "do it right".  Let's.

I understand that my primary argument is from theory rather than from
more practical considerations (with the exception of the "state" part
of the argument).  However, as my college roommate said when I showed
him why his program would be better off coded as a finite-state automa-
ton: "Wow, that theory class was actually good for something."  As true
today, decades later.

Joe Yao				jsdy@cais.com - Joseph S. D. Yao

* Also, most of the kernel and system changes I've made weren't easily
  folded back into the distributed versions (from a procedural and
  administrative point of view).



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []