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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
