Re: why not mingetty??
On Sat, Apr 25, 1998 at 11:14:56AM -0400, Raul Miller wrote:
> > That's not true, it is -- getty requires a speed, even for a virtual
> > terminate, while mingetty doesn't support that.
>
> Does this mean that mingetty won't ignore this argument? That
> should be fixed, in my opinion.
It should ignore arguments? That's not exactly Principle-of-least-surprise
compliant :)
getty_ps uses arbitrarily different options, as does mgetty. There's not
much point in making mingetty try to be the same as agetty if the others
aren't. Besides, virtual terminals don't need baud rates.
Plus, adding support for this means adding more useless code to mingetty,
which defeats its purpose.
> > As to the numbers, I just started up a getty on my box here:
> >
> > yodeller# ps aux | grep getty
> > root 384 0.0 0.0 720 0 2 SW Feb 9 0:00 (mingetty)
> > root 401 0.0 0.0 720 0 1 SW Feb 9 0:00 (mingetty)
> > root 10361 0.5 1.4 868 460 3 S 17:07 0:00 /sbin/getty 38400 tty
>
> This is not a completely reasonable comparison (though it does show
> 0:00 time used by each getty, which is perhaps significant).
It's not very useful. Virtual size is pretty pointless when comparing
memory usage -- I've had programs that used "virtually" hundreds of megs
without digging into swap. It's just that they allocated it without using
it, or mmapped large files. Most shared libraries cause arbitrarily bloated
virtual memory.
RSS is the only reasonable value for comparison, and since your quoted
getties are swapped out to different degrees, we can't get an accurate one.
On my system:
root 15982 0.4 0.8 736 344 7 S 21:47 0:00 /sbin/mingetty tty7
root 15983 0.4 1.1 860 456 2 S 21:47 0:00 /sbin/getty 9600 tty2
I just disabled my swap space and freshly restarted these tasks. RSS
difference is 456 - 344 = 112k of savings. Considering my ever-increasing
impression that "shared" pages don't actually work for separately-started
copies of the same binary, and the simple truth that data pages can't be
shared between these, I'd say a good part of that 112k is then multiplied by
the number of getties you run.
And as for speed... well, they both use 0:00 seconds of CPU time, but agetty
takes a full second longer to start. (This is almost certainly a DTR-drop
to make modems happy; since we don't deal with modems, we don't have the
drop or the wait. It feels faster, and that's a big psychological benefit.)
> (b) On the other hand, in my informal testing, I couldn't get mingetty
> to run -- apparently, it can't do TIOCSCTTY on my system, so it bails
> out.
Hmm. Works for me. Of course, you do have to run it from init. TIOCSCTTY
is one of the pickiest bloody system calls I've ever seen.
> (d) Technically, you also need to compare console handling to console
> handling, not console handling to serial handling.
Incidentally, agetty's serial handling is completely atrocious anyway. For
serial terminals, you should seriously use getty_ps. For modems, use
mgetty. For consoles, use mingetty. See, agetty is obsolete :)
Seriously, though, the very early getties (of which agetty is one, and
getty_ps is another) tried to be an all-in-one completely scriptable
terminal handler. This approach failed dismally with modems, and wasn't
necessary for terminals. Have you ever tried to make agetty answer a phone
at arbitrary baud rates with a 2400 baud modem? Yes, it can be done, I did
it. Have you ever tried to do it reliably? If you did that, you have me
beat.
If we added a tiny enhancement to mingetty to let it set the baud rate and
TERM variable, then it would be completely capable of handling serial
terminals as well as the VTs. Then you just need mingetty/mgetty for
complete flexibility. Meanwhile, people with serial terminals can just use
agetty for those. That's not very hard.
The main reason mingetty is smaller than agetty is the absence of the
scripting junk, I think.
> Finally, note that if we get too fancy it will be tough for people who
> need to use multiple gettys on the same system (but maybe that's only
> important for testing purposes).
I don't think there's a need for alternatives and all that. Is there?
Perhaps the sysvinit (or some other) install script could just comb through
/etc/inittab and offer to replace the getty entries it recognizes with
mingetty lines.
Have fun,
Avery
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: