jon@nsc.UUCP (01/28/87)
Does anyone know a simple method to "turn a port around" so as to make an outgoing call on a port which is usually used for incoming connections? I can imagine a messy shell script (run by root) to kill the getty, make the call, and restore the getty. Has anyone written such a script? Is there a better way? How do you handle problems, if any, with the modem? (We are currently using Hayes Smartmodems.) Please reply by mail. If anything interesting appears, I will summarize, probably to Net.sources. Thanks:
mouse@mcgill-vision.UUCP (02/02/87)
In article <4090@nsc.nsc.com>, jon@nsc.nsc.com (Jon Ryshpan) writes: > Does anyone know a simple method to "turn a port around" so as to > make an outgoing call on a port which is usually used for incoming > connections? What we did was to put a special getty on the line, one which just waits for either (a) input from the port, in which case it execs login, or (b) a SIGTERM, in which case it releases the port for uucp's use but does not exit (so init doesn't fork another). Then the uucp job runs as root (ok since uucico runs setuid uucp) and sends the getty a SIGTERM before and SIGKILL after running uucico. Note that the fake getty can be very simple since it doesn't need to read a username and it never needs to take the port back after letting it go (it's killed and init forks another one). > How do you handle problems, if any, with the modem? (We are > currently using Hayes Smartmodems.) We use Racal-Vadic modems and they don't cause us any grief with this scheme. der Mouse USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse think!mosart!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu
jc@piaget.UUCP (02/09/87)
In article <4090@nsc.nsc.com> jon@nsc.UUCP (Jon Ryshpan) writes: >Does anyone know a simple method to "turn a port around" so as to >make an outgoing call on a port which is usually used for incoming >connections? I can imagine a messy shell script (run by root) to kill >the getty, make the call, and restore the getty. Has anyone written >such a script? Is there a better way? How do you handle problems, if >any, with the modem? (We are currently using Hayes Smartmodems.) > >Please reply by mail. If anything interesting appears, I will >summarize, probably to Net.sources. > >Thanks: HDB uucp permits this. A separate getty (uugetty) is fired up for such lines. Uugetty locks the port with a lock file. I do not know the mechanism for making uugetty unconcious but I presume that a signal is used. When uucico is done with all uucp transactions (or when cu/tip exit) they inform uugetty (or init and again presumably via a signal) that they are done and uugetty does its thing. Lock files are used heavily in this implementation. The concept of a separate getty for bidirectional lines is a good one and seems to work pretty well. I am given to understand that BSD also has this feature. -- John Cornelius (...!sdcsvax!piaget!jc)
misko@ohlone.UUCP (02/10/87)
/* Written 10:11 am Feb 9, 1987 by piaget.UUCP!jc in ohlone:comp.sources.w */ /* ---------- "Re: UUCP Port Turnaround" ---------- */ In article <4090@nsc.nsc.com> jon@nsc.UUCP (Jon Ryshpan) writes: >>Does anyone know a simple method to "turn a port around" so as to >>make an outgoing call on a port which is usually used for incoming >>connections? I can imagine a messy shell script (run by root) to kill >>the getty, make the call, and restore the getty. Has anyone written >>such a script? Is there a better way? How do you handle problems, if >>any, with the modem? (We are currently using Hayes Smartmodems.) >> >>Please reply by mail. If anything interesting appears, I will >>summarize, probably to Net.sources. >> >>Thanks: >HDB uucp permits this. A separate getty (uugetty) is fired up >for such lines. Uugetty locks the port with a lock file. uugetty does not lock the port (with a lock file) until someone attempts to login. The way uugetty determines if someone is trying to login is that it waits to see a character. Upon receiving 1 character, uugetty assumes that someone is logging in, locks the port and starts the login process (sending out login:, etc.). This works quite well except for when you are using certain modems. The modems we are using are Hayes compatible. Unfortunately, they must always have DCD raised for cu to work. This is because cu waits for DCD. If DCD is not up, cu times out with a DEVICE UNAVAILABLE error message. Same with uucico. The problem with always having DCD up is that our modems send out "RING" when the phone rings. uugetty sees this and thinks that someone is trying to login. If it was a wrong number, you run into problems. uugetty sends out "login:", the modem echo's it, uugetty echo's it, the modem echo's it, etc. etc. etc. ad infinitum. Really grinds the machine to a halt. We have a fix for this, but it required changing cu, uucico, and uugetty. We are running HDB uucp on an AT&T 3b2/400 running Sys V 3.0. Bill Miskovetz Cray Research {ihnp4, lll-lcc}!ohlone!misko
wescott@sauron.UUCP (02/11/87)
In article <166@piaget.UUCP> jc@piaget.UUCP (John Cornelius, System Manager) writes: > In article <4090@nsc.nsc.com> jon@nsc.UUCP (Jon Ryshpan) writes: > >Does anyone know a simple method to "turn a port around" so as to > >make an outgoing call on a port which is usually used for incoming > >connections? ... > HDB uucp permits this. A separate getty (uugetty) is fired up > for such lines. Uugetty locks the port with a lock file. I do > not know the mechanism for making uugetty unconcious but I > presume that a signal is used. The HDB uugetty waits until the line is active before checking for a lock. The line is active when the open completes (i.e. Carrier Detect is on) or, if uugetty is invoked with a '-r' option, when the first character is received. uugetty checks the lock file for the line and if the file is not present or if it contains an old pid, uugetty sets a new lock and continues much like /etc/getty. Note that nobody removes this lock file until a new uugetty or uucico finds that the pid in it is no longer valid. If a valid lock is present, then uugetty loops sleeping and rechecking the lock. When the locking process has terminated, uugetty exits and is respawned by init. The HDB uugetty will not work on 4.? machines because of the mechanism used to check locks. -- -Mike Wescott ncrcae!wescott
guy@gorodish.UUCP (02/12/87)
>The HDB uugetty will not work on 4.? machines because of the mechanism used >to check locks. If this refers to the comment /* It will only work on USG systems at least 5.0 or systems */ /* that permit kill(0, pid). */ in the "uugetty" source and the comment * check to see if the lock file exists and is still active * - use kill(pid,0) - (this only works on ATTSV and some hacked * BSD systems at this time) in "ulockf.c", note that 4.[23]BSD *are* systems that permit "kill(0,pid)" and, as such, support this just fine. However, "uugetty" also requires other administrative goo from S5, so it won't just drop in, and you'd better be able to use it on *all* ports if you're running vanilla 4.2BSD, since its "init" always runs "getty" on all ports. I'm not sure I care for the notion of something that's almost, but not quite, the same as "getty"; the two programs can easily get out of sync. I've seen solutions proposed where you have two "devices" associated with a terminal port, one for dialing out and one for other uses. "getty" opens the "other uses" device and waits for the open to complete, i.e. it waits for carrier to come up. "uucp", etc. open the "dialing out" device, which does *not* wait for carrier to come up (since most auto-call units these days are driven by writing stuff to the modem directly before carrier is established). If this succeeds, then the modem will (one hopes) give a busy signal as soon as it's told to pick up the phone and start dialing, and perhaps will refuse to answer the phone as soon as the program doing the dialing tells it that it's about to start using it to dial out. (The kernel could, conceivably, refuse to acknowledge carrier coming up if the dialout device is open, but this means the dialing program couldn't wait for carrier to come up after dialing without closing the dialout device.) If "getty" is waiting for the open to complete, and somebody dials in, causing the open to complete, all opens of the dialout device are blocked (they return EBUSY or something like that). This tells "uucp", etc. to try again later or try another port. When the dialin device is closed, dialout opens are again permitted. This pretty much obviates the need for changes to "getty", etc..
gemini@homxb.UUCP (02/14/87)
In article <13135@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > I'm not sure I care for the notion of something that's almost, but > not quite, the same as "getty"; the two programs can easily get out > of sync. I've seen solutions proposed where you have two "devices" > associated with a terminal port, one for dialing out and one for > other uses. ... more stuff about modifiying the kernel for two devices ... Venturcom's VENIX did (still does) have hacks like these in the kernel tty driver. I was never successful in getting dial-in/out to work with either a Rixon modem, or an AT&T Aztec protocol modem, although the claim was that they worked (mostly?) with Hayes modems. As far as I'm concerned, hacking the kernel ISN'T the way to go. The HDB uugetty program also didn't turn the trick for me either. I gave up on that approach months ago as a waste of time. Then, lo, out of the public domain comes "modem". It needed just what the author claimed: to be made aware of lock file location and naming conventions and to know the sequence the modem uses when answering a call. Jeeze, that little sucker was up on my machine in an hour. And it worked, mostly. The only hacks I added were to not open the serial port until after the port becomes free (to make sure the phone gets hung up immediately after an outgoing call has finished), and to add a "send" sequence for forcing hangup (to guarantee a clean start for talking to the modem. It's short, sweet, for free, you get the source, and it works. Save the kernel mods for when they're really needed. As for me, I'm happy with two versions of 'getty'. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.
rick@seismo.UUCP (02/15/87)
I am currently using the acucntrl hack on a 4.3BSD vax and the kernel hack variation on a Sun 3.2 3/160. The kernel hack is infintely preferable. No screwing around with killing init, changing /etc/ttys, etc. You don't even have modify the user level software. You should try the kernel hack on a decent system before dismissing it. ---rick
gemini@homxb.UUCP (02/15/87)
In article <43099@beno.seismo.CSS.GOV>, rick@seismo.CSS.GOV (Rick Adams) writes: > > I am currently using the acucntrl hack on a 4.3BSD vax and the > kernel hack variation on a Sun 3.2 3/160. > > You should try the kernel hack on a decent system before dismissing it. I guess it's just the Berkeley philosophy to do things in the kernel whenever possible, even when it's not necessary. Rick Richardson, PC Research, Inc. (201) 922-1134 ..!ihnp4!castor!pcrat!rick <--Replies to here, not to homxb!gemini, please.
guy@gorodish.UUCP (02/15/87)
>Venturcom's VENIX did (still does) have hacks like these in the kernel >tty driver. I was never successful in getting dial-in/out to work with >either a Rixon modem, or an AT&T Aztec protocol modem, although the >claim was that they worked (mostly?) with Hayes modems. As far as >I'm concerned, hacking the kernel ISN'T the way to go. Concluding from one implementation that the concept being implemented is wrong is foolish. Do you have any evidence that the problems with VENIX were caused solely by the fact that they modified the kernel? >The HDB uugetty program also didn't turn the trick for me either. I >gave up on that approach months ago as a waste of time. > >Then, lo, out of the public domain comes "modem".... The only reason you didn't decide that doing it with two flavors of "getty" wasn't also the way to go seems to be that you eventually ran across something using two versions of "getty" that worked. As such, you know that concluding that some approach is wrong based on the first implementation you see is wrong, and should not have drawn the conclusion you did about kernel mods. >Save the kernel mods for when they're really needed. Sigh. What does "really needed" mean here? The advantage of the kernel mods, as Rick Adams pointed out, is that you don't have to teach several programs about how to share modem lines. >As for me, I'm happy with two versions of 'getty'. Well, you don't have to maintain them and keep them in sync.
chris@mimsy.UUCP (02/15/87)
>In article <43099@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: >>You should try the kernel hack on a decent system before dismissing it. In article <2388@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >I guess it's just the Berkeley philosophy to do things in the kernel >whenever possible, even when it's not necessary. No, and that was a cheap shot. A few points: - Berkeley does not have the line turnaround in the kernel. - It *is* necessary, for security if nothing else. The first is unarguable. As to the second, think about all the ways to confuse people dialing in. You will wind up with only root being able to do certain things to modem lines. The kernel does not now enforce that, so you will have to change it somehow. (vhangup() almost works, but one can get around it.) Why not make the (trivial) changes required to do line turnaround there too? It costs a few bytes of code, and one extra cdevsw[] entry, per kind of terminal multiplexor, and two extra bits of data per line. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
guy@gorodish.UUCP (02/16/87)
>> You should try the kernel hack on a decent system before dismissing it. > >I guess it's just the Berkeley philosophy to do things in the kernel >whenever possible, even when it's not necessary. Oh, good grief! 1) The change was made by Sun, not Berkeley; if you'd read Rick Adams' article carefully, you would have seen that. 2) There are plenty of things in plenty of kernels that don't, strictly speaking, *have* to be there. Why is file name to i-number translation in the UNIX kernel? Why is canonical-mode tty processing in the UNIX kernel? It is certainly *convenient* to put them there, because it means that applications don't need to do those things themselves, and they can share common code to do this. The very same thing can be said about arbitrating access to dial-in/dial-out lines. Putting it in the kernel (and it's *not* a lot of code, believe me - probably less than 1KB, and probably less than the code you have to add to the system if you don't do it in the kernel!) means that, as Rick pointed out, you *don't* have to modify "getty" or "uucp" or anybody else that wants to dial out. 3) Casually claiming that there's some kind of "Berkeley philosophy" that "puts things into the kernel whenever possible" may be satisfying, but it's not true. What are these "things" you're referring to?
paul@vcvax1.UUCP (02/16/87)
> > of sync. I've seen solutions proposed where you have two "devices" > > associated with a terminal port, one for dialing out and one for > > other uses. > > Venturcom's VENIX did (still does) have hacks like these in the kernel > tty driver. Actually, we took these hacks out in VENIX System V, since, as Rick pointed out, they didn't work too well, due to problems that did not appear easily solvable. Instead, we added the "ttystate" command, a shell script which (carefully) manipulates the inittab and turns off and on getty processes. (I posted this to the net a while ago.) A uudemon script can use this to disable the getty before dialing out. This approach has proved more reliable. Paul Kleppner VenturCom, Inc. 617/661-1230 {seismo!harvard,genrad!mit-eddie}!cybvax0!vcvax1!paul
paul@vcvax1.UUCP (02/16/87)
> >Venturcom's VENIX did (still does) have hacks like these in the kernel > >tty driver .... As far as > >I'm concerned, hacking the kernel ISN'T the way to go. > > Concluding from one implementation that the concept being implemented > is wrong is foolish. Do you have any evidence that the problems with > VENIX were caused solely by the fact that they modified the kernel? Since I was involved with the implementation of these features in VENIX, let me add my eight bits on the subject. First, I think there are two problems being discussed here: the switching of terminal lines from dial-in to dial-out (i.e., disabling getty), and then the actual dialing of the terminal lines. Regarding the first problem (disabling getty): The implementation Rick Richardson referred to in VENIX V2 involved modifications to the com drivers, not to the generic tty code itself. The problems that arose seemed to me to be due to complicated states occuring when the same tty line was opened simultaneously by two or more processes, one of which might be blocking on output, or waiting for carrier, while another might be trying to dial-out and avoid waiting for carrier. The generic tty code was not designed to handle these situations very well, and, after wrestling with the driver code for a while, we eventually concluded that the problem could be more easily solved at the user level, particulary since UNIX System V allowed us to easily disable and enable getty processes through the telinit command. Perhaps we would have been better of with an implementation that involved changes to tty.c, as Rick Adams' appeared to do. Our user-level solution to the problem is through the "ttystate" command, which uses telinit to control the lines. Uucp demon scripts must explicity use ttystate to control the line. This is certainly clumsier than the kernel-level solution, which implictly changes the state as needed. On the other hand, if a problem arises, it is much easier to straighten things out at the user level that it is at the kernel level. My conclusion is: if the kernel solution *really* works perfectly, I think it's much nicer. However, if problems ever arise, I prefer our user-level approach. Finally, I should add that the problems in VENIX V7 were compounded by the second of the two problems mentioned above: the lack of smart-modem dialing software. We've addressed that in VENIX System 5 with a separate program which JUST dials modems. (The program is also called "modem", but I don't think it's the "modem" that Rick Richardson referred to in his first posting.) This program doesn't get involved with changing the tty state; all it does is drive modems. Uucp communicates with it via a FIFO, and it emulates an ACU device. We thus provided reasonable modem dialing without modifying a line of the UNIX 5.2 uucp code. Paul Kleppner VenturCom, Inc. 617/661-1230 {seismo!harvard,genrad!mit-eddie}!cybvax0!vcvax1!paul
mcvoy@uwvax.UUCP (02/16/87)
In article <13355@sun.uucp> guy@sun.UUCP (Guy Harris) writes: In some article somewhere somebody (Some Body) writes: - >> You should try the kernel hack on a decent system before dismissing it. - > - >I guess it's just the Berkeley philosophy to do things in the kernel - >whenever possible, even when it's not necessary. - - Oh, good grief! - - 2) There are plenty of things in plenty of kernels that don't, - strictly speaking, *have* to be there. Why is file name to i-number - translation in the UNIX kernel? Why is canonical-mode tty processing - in the UNIX kernel? - - 3) Casually claiming that there's some kind of "Berkeley philosophy" - that "puts things into the kernel whenever possible" may be - satisfying, but it's not true. What are these "things" you're - referring to? [Try: network code, yellow pages, file servers, page management (yes, I meant that), tty drivers (you're right Guy, they shouldn't be there unless needed, see version 8), etc. What's the old kernel up to these days, a meg and a half or so?] My guess, Guy, is that the person in question was referring to the the _commonly_ held belief that the Berkeley kernel is too large and seems to be growing without bounds. I don't think that there is a "Berkeley philosophy" (or a Sun version either) that says "When in doubt, throw it in the kernel". I think that it is much more likely that the hacker of the moment couldn't see an easier way. So, rather than blasting this poor soul into Unix exile, why don't we take a look at why the kernel is so big and what can be done about (and even, do we want to do anything about it)? Anyone who uses BSD unix, especially systems programmers, tends to like it a lot (alright, a blatent overstatement, but some people like it). The point is that, if you start taking away the functionality of the current BSD release, people will be unhappy (and rightly so, try doing network type code without select someda). So we don't want that... Anyone who has to maintain the kernel tends to lose their lunch upon looking at it for the first time. Here a hack, there a hack, everywhere a hack-hack. My God, that *is* the kitchen sink, isn't it :-? The problem is that we all like the kernel from the outside, but only a select masochistic few like it from the inside. Right? Well, why don't we take a look at redesigning the kernel? The goal would be 2 part: 1) Maintain complete compatibility with the current (or even future) BSD release(s). In other words, it has to work the same as BSD. 2) Redesign the internal structure to allow easier maintainence and flexibility (aka modular design. Yeah, I hate them software engineering words too). Break it up into the logical parts and define some cleaner interfaces. Sounds good, you say? Sounds impossible, too? Sounds possible, but slow? The last one has it. This has already been done folks, the people at CMU have something called MACH that fulfills both goals. It's a message passing kernel based on Accent that is binarily compatible with 4.3BSD on Vax, source compatible elsewhere. It's supposedly well designed, easy to maintain, and has some new features that make Unix look sick (like copy-on-write MM, used to get pass-by-value saftey with pass-by-reference speed, msg based so networking is cake, user loadable drivers, pagers, etc). Oh yeah, almost forgot, they have light weight processes to address the speed issue (all kernel processes are light weight) and they claim to have performance comparable (in some cases better than) to a BSD implementation. Check it out. So, Guy, the person you blasted was not so far off base, methinks. You don't want me to think that you, of all people, like the fact the kernel is huge and cumbersome, do you? Or does playing wizard really mean that much to you? Food for thought, --larry -- Larry McVoy mcvoy@rsch.wisc.edu, {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy "They're coming soon! Quad-stated guru-gates!"
mwm@eris.UUCP (02/17/87)
In article <3233@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >In article <13355@sun.uucp> guy@sun.UUCP (Guy Harris) writes: >In some article somewhere somebody (Some Body) writes: >- >I guess it's just the Berkeley philosophy to do things in the kernel >- >whenever possible, even when it's not necessary. >- >- 3) Casually claiming that there's some kind of "Berkeley philosophy" >- that "puts things into the kernel whenever possible" may be >- satisfying, but it's not true. What are these "things" you're >- referring to? > >[Try: network code, yellow pages, file servers, page management (yes, I > meant that), tty drivers (you're right Guy, they shouldn't be there > unless needed, see version 8), etc. What's the old kernel up to these > days, a meg and a half or so?] Berkeley hasn't put yellow pages & file servers in the kernel; those are from Sun. The tty driver was inherited from v7; I don't know anybody who doesn't think it needs a rewrite. That leaves networking and page management, which people tend to put into the kernel for efficiency reasons. >My guess, Guy, is that the person in question was referring to the >the _commonly_ held belief that the Berkeley kernel is too large Possible. But that belief is also common around Berkeley. The question is how to cleanly get from where we are to where we want to be. >Anyone who has to maintain the kernel tends to lose their lunch upon >looking at it for the first time. Here a hack, there a hack, everywhere a >hack-hack. My God, that *is* the kitchen sink, isn't it :-? Anyone who ever grows past the stage of being able to look at kernel code without wanting to loose their lunch needs help. Fortunately, there's usually a sink handy :-). >[Talk about redesigning the kernel.] >The last one has it. This has already been done folks, the people at >CMU have something called MACH that fulfills both goals. Yeah, and the MACH kernel is the second-largest kernel I've ever run. The largest is ultrix-2, with NFS, SVID compatable up to and including shared memory, support the an entire new bus structure, and a second processor. Also, last time I looked (about 6 months ago), a lot of the neat features in MACH weren't. Lightweight processes, user-mode file servers, user-mode 4.3 emulation, etc. Large parts of the kernel were also 4.3, not MACH. Changing these things could make the kernel smaller; they could also make it slower. Of course, the parts that were MACH were readable. MACH is worth watching; as it might turn out to be the classic "smaller & faster & more functional than the original" type clone. But I'd expect "bigger & slower and more functional," which means I'm not interested (BSD is big & slow & functional enough as it is). <mike But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET
gemini@homxb.UUCP (02/17/87)
In article <13332@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > Sigh. What does "really needed" mean here? The advantage of the > kernel mods, as Rick Adams pointed out, is that you don't have to > teach several programs about how to share modem lines. Teach which several programs? No mods were needed to uucico, getty, login, cu, etc. In fact, the modem program exec's getty, once it's decided there's an incoming call. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 ..!ihnp4!castor!pcrat!rer} <--Replies to here, not to homxb!gemini, please.
gemini@homxb.UUCP (02/17/87)
In article <13355@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: > >> You should try the kernel hack on a decent system before dismissing it. > >I guess it's just the Berkeley philosophy to do things in the kernel > >whenever possible, even when it's not necessary. > Oh, good grief! > > 1) The change was made by Sun, not Berkeley; if you'd read Rick > Adams' article carefully, you would have seen that. I said "Berkeley philosophy", I didn't say that Berkeley made the change. I was referring to those 300K kernels I've seen running 4.2BSD and derivatives. Christ, there sure as hell's got to be a load of baggage in there that doesn't need to be there. Let's be sane about this, line turnaround might be a nearly free kernel feature, then again, it might be painful. You need to make the mods (correct me) in each serial device driver? And many (most) users don't care about it one way or another. It's for the little guy with just one serial port, one phone line. The big guys have absolutely dumb (read cheap) modems on all the dial-ins, and a couple of autodialers on the dial-outs. Yeh, I'm a little guy. I need it. "Modem" sits out there on the swap device nearly all day, all 14K of him. SVR2 sits in core all day, all 100K of him. If your kernel's big already, a little more won't hurt. But mines small, I'd like to keep it that way. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.
chris@mimsy.UUCP (02/17/87)
In article <3233@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >My guess, Guy, is that the person in question was referring to the >the _commonly_ held belief that the Berkeley kernel is too large >and seems to be growing without bounds. >So, rather than blasting this poor soul into Unix exile, why don't we >take a look at why the kernel is so big and what can be done about >(and even, do we want to do anything about it)? (I think we do, but just what must still be classified `experimental'.) >Well, why don't we take a look at redesigning the kernel? The goal would be >2 part: > > 1) Maintain complete compatibility with the current (or even future) > BSD release(s). In other words, it has to work the same as BSD. To quote from /sys/sys/ufs_xxx.c: /* * Oh, how backwards compatibility is ugly!!! */ As for myself, I am not sure compatibility is worth the ugliness. > 2) Redesign the internal structure to allow easier maintainence and > flexibility (aka modular design. Yeah, I hate them software > engineering words too). Break it up into the logical parts > and define some cleaner interfaces. > >Sounds good, you say? Sounds impossible, too? Sounds possible, but slow? >The last one has it. This has already been done folks, the people at >CMU have something called MACH that fulfills both goals. ... Oh yeah, >almost forgot, they have light weight processes to address the speed >issue (all kernel processes are light weight) and they claim to have >performance comparable (in some cases better than) to a BSD implementation. Mach is still `under development'; it remains to be seen whether all this will really fly. And if you thought 4.3BSD was big. . . . To be fair, while the Mach kernel is about twice the size of the 4.3 kernel, it does have full 4.1BSD compatibility, and 4.2 compatibility, and . . . well, you probably get the idea. CMU is big on compatibility. (If you had thousands of students using thousands of programs and only tens of people to update them, I imagine you would be big on compatibility too.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
guy@gorodish.UUCP (02/17/87)
>[Try: network code, yellow pages, You lose, Larry, YP is NOT in the kernel. > file servers, page management (yes, I meant that), tty drivers >(you're right Guy, they shouldn't be there unless needed, see version 8), So is the TTY driver, even in version 8. >etc. What's the old kernel up to these days, a meg and a half or so?] gorodish$ size /vmunix text data bss dec hex 445120 77784 120348 643252 9d0b4 Try again. (This is a kernel with lots of bits under development, too, so a lot of that stuff will go away eventually.) >My guess, Guy, is that the person in question was referring to the >the _commonly_ held belief that the Berkeley kernel is too large >and seems to be growing without bounds. There are lots of commonly held beliefs; the fact that a belief is commonly held does not necessarily mean that it is true. As for singling out the Berkeley kernel, I shall point out that I just did a "size" on "/unix" on a 3B2 around here, and it was about 800KB. >Sounds good, you say? Sounds impossible, too? Sounds possible, but slow? >The last one has it. This has already been done folks, Yes, I knew about Mach long before your posting. >So, Guy, the person you blasted was not so far off base, methinks. The person in question specifically claimed that the "Berkeley philosophy" was to shove everything into the kernel. So no, he really *was* far off base; think again. >You don't want me to think that you, of all people, like the fact the kernel >is huge and cumbersome, do you? Or does playing wizard really mean that >much to you? I don't really *care* what you think, and no, playing wizard doesn't really mean that much to me. Does putting out a large and somewhat incoherent bit of meandering mean that much to you? More facts, less blather, next time, please.
guy@gorodish.UUCP (02/17/87)
>I said "Berkeley philosophy", I didn't say that Berkeley made the change. If Berkeley didn't make the change, then you shouldn't have said "Berkeley philosophy"! Blaming it on some alleged "Berkeley philosophy" is just venting prejudices based on misinformation. >I was referring to those 300K kernels I've seen running 4.2BSD and >derivatives. We've got a 3B2 in our lab; it's definitely *not* running 4.2BSD or a derivative, and its kernel is bigger than the one on my workstation. Yes, kernels are getting big, but blaming this on Berkeley is ridiculous. >Christ, there sure as hell's got to be a load of baggage >in there that doesn't need to be there. I only accept statements like this from people who can list the aforementioned "baggage" and can give *good* reasons why it doesn't need to be there. There probably is stuff that could be cleaned out, but I'd rather hear an *informed* opinion on that than an offhand casual remark. >Let's be sane about this, line turnaround might be a nearly free kernel >feature, then again, it might be painful. Yes, it might be either, which means your comment was content-free. >You need to make the mods (correct me) in each serial device driver? Yes, but rejecting such a change based on that, without looking at the costs and benefits, is simply wrong. >And many (most) users don't care about it one way or another. It's for >the little guy with just one serial port, one phone line. The big guys >have absolutely dumb (read cheap) modems on all the dial-ins, and a couple >of autodialers on the dial-outs. I got news for you; "seismo.css.gov" is not a "little guy with just one serial port, one phone line", it's a major UUCP and Internet site with many lines. Rick found a small kernel hack worked quite well. If you're going to spout off, make sure you know what you're talking about first!
jim@strath-cs.UUCP (02/18/87)
In article <3233@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >.. the people at CMU have something called MACH .... It's a message >passing kernel based on Accent that is binarily compatible with 4.3BSD on >Vax, source compatible elsewhere. It's supposedly well designed, >easy to maintain, and has some new features that make Unix look sick (like >copy-on-write MM, used to get pass-by-value saftey with pass-by-reference >speed, msg based so networking is cake, user loadable drivers, pagers, etc). Granted MACH has lots of interesting things in it, but it is HUGE. Even a BSD kernel pales into insignificance. I recall someone from CMU saying that their development kernel had a 700K text segment! OK - it may have had lots of redundant code for development work, but I can't see how MACH could be smaller than a comparable Berkeley kernel with all these nice new ideas that CMU are implementing. The MACH kernel source might be prettier, but can we afford the extra core needed to run it? :-) Jim
brunner@sri-spam.UUCP (02/19/87)
>I got news for you; "seismo.css.gov" is not a "little guy with just >one serial port, one phone line", it's a major UUCP and Internet site >with many lines. Rick found a small kernel hack worked quite well. >If you're going to spout off, make sure you know what you're talking >about first! Say Guy, you don't mean to imply that this gent's view of the internet has seismo cast as a shoebox do you? Cheers! Eric -- how about a great big spidery "X"?
jbs@mit-eddie.UUCP (02/20/87)
In article <395@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk writes: >I recall someone from CMU saying >that their development kernel had a 700K text segment! > >The MACH kernel source might be prettier, but can we afford the extra core >needed to run it? :-) 4Mbytes of MicroVAX memory is available for well under $2K. Memory prices for other systems are likely to be similar. While large size may be interpreted (correctly or incorrectly) as poor design, arguing against something because of its size (measured in K bytes) seems silly, especially when additional (useful) features (like improved maintainability) are involved. Jeff Siegal
brandon@tdi2.UUCP (02/20/87)
Quoted from <13355@sun.uucp> ["Re: UUCP Port Turnaround"], by guy%gorodish@Sun.COM (Guy Harris)... +--------------- | >> You should try the kernel hack on a decent system before dismissing it. | > | >I guess it's just the Berkeley philosophy to do things in the kernel | >whenever possible, even when it's not necessary. | | Oh, good grief! | | Putting it in the kernel (and it's *not* a lot of code, believe me - | probably less than 1KB, and probably less than the code you have to | add to the system if you don't do it in the kernel!) means that, as | Rick pointed out, you *don't* have to modify "getty" or "uucp" or | anybody else that wants to dial out. +--------------- I'm running System V.2 (yes, *that*). The inittab and special init states a, b, c make life a lot easier. -------------- uugetty.sh -------------- tty="`echo $1 | sed 's:/dev/::'`" while test -f /usr/spool/uucp/uulk."$tty" -o -f /usr/spool/uucp/LCK.."$tty"; do sleep 300 done exec /etc/getty "$@" -------------- uulock.sh -------------- : usage="usage: $0 [-lu] tty" job=lock exec > /dev/syscon 2>&1 case "$1" in -l) job=lock shift ;; -u) job=unlock shift ;; esac case "$#$1" in 1*) ;; *) echo "$usage" exit 1 esac who -a > /tmp/uul$$ case "$job" in unlock) grep "^uugetty /dev/$1 " /tmp/uul$$ > /dev/null 2>&1 || { echo "$0: device /dev/$1 is unlocked or nonexistent" /bin/rm /tmp/uul$$ exit 3 } ;; *) grep "^LOGIN /dev/$1 " /tmp/uul$$ > /dev/null 2>&1 || { echo "$0: device /dev/$1 is busy or nonexistent" /bin/rm /tmp/uul$$ exit 2 } esac case "$job" in unlock) /usr/lib/uucp/hup $1 rm -f /usr/spool/uucp/uulk.$1 ;; *) touch /usr/spool/uucp/uulk.1 set -- `grep "^LOGIN /dev/$1 " /tmp/uul$$` kill -9 $7 esac rm -f /tmp/uul$$ ------------- NOTE: /usr/lib/uucp/hup simply sends an ATZ to the modem to make it happy. A smarter UUCP or getty or etc. could do this as well. ------------- /etc/inittab (partial) ------------- 22:2:respawn:/etc/uugetty /dev/tty22 M1200 #Remote Dial-In ul:b:wait:/etc/uulock -l tty22 # lock it uu:c:wait:/etc/uulock -u tty22 # unlock it The only oddness is in killing the existing getty; if there is none, the program knows it's either locked already or in use. This is probably adaptable to BSD, given that BSD has a ttys file that lets you say what getty to run on a port. The telinit b/c stuff from System V is just handy; it's by no means necessary. However, you'll have to change the utmp-checking code in uulock.sh to check processes instead. ++Brandon -- ``for is he not of the Children of Luthien? Never shall that line fail, though the years may lengthen beyond count.'' --J. R. R. Tolkien Brandon S. Allbery UUCP: cbatt!cwruecmp!ncoast!tdi2!brandon Tridelta Industries, Inc. CSNET: ncoast!allbery@Case 7350 Corporate Blvd. INTERNET: ncoast!allbery%Case.CSNET@relay.CS.NET Mentor, Ohio 44060 PHONE: +1 216 255 1080 (home) +1 216 974 9210
terryl@tekcrl.UUCP (02/21/87)
In article <395@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk writes: +In article <3233@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: +>.. the people at CMU have something called MACH .... It's a message +>passing kernel based on Accent that is binarily compatible with 4.3BSD on +>Vax, source compatible elsewhere. It's supposedly well designed, +>easy to maintain, and has some new features that make Unix look sick (like +>copy-on-write MM, used to get pass-by-value saftey with pass-by-reference +>speed, msg based so networking is cake, user loadable drivers, pagers, etc). + +Granted MACH has lots of interesting things in it, but it is HUGE. Even +a BSD kernel pales into insignificance. I recall someone from CMU saying +that their development kernel had a 700K text segment! OK - it may have +had lots of redundant code for development work, but I can't see how MACH +could be smaller than a comparable Berkeley kernel with all these nice new +ideas that CMU are implementing. I was going to stay out of this, but here are some sizes on /vmunix from various machines I use: text data bss dec hex 192040 88216 98800 379056 5c8b0 /vmunix, VAX 11/780 running 4.3 text data bss dec hex 311108 44472 140656 496236 7926c /vmunix, same VAX running mach text data bss dec hex 253056 24436 69342 346834 54ad2 /vmunix, 68010 workstation with 4.2 text data bss dec hex 246944 30532 39356 316832 4d5a0 /vmunix, 68020 workstation with 4.2 NOTE: these sizes do NOT include all of the data structures allocated dynamically, i.e. disk buffers, in-core inodes, file structs, etc. Also, the workstations are running significantly different flavors of 4.2, with the 68010 workstation more vanilla 4.2. Both workstations also have some sort of remote file system, whereas the VAX does not. Last note: the 68020 workstation kernel was compiled using the Greenhills compiler, whereas the 68010 was compiled with the MIT. I would guestimate that the 68010 kernel would probably shrink by 10-15% by using the Greenhills compiler. +The MACH kernel source might be prettier, but can we afford the extra core +needed to run it? :-) Uh, I hate to burst your bubble, but the MACH sources are definitely NOT prettier. They have made some strides, but unfortunately, there are still a lot of VAX'isms sprinkled throughout the code. Also, MACH hasn't quite split things up into machine-independent and machine-dependent sources, most specifically in the VM subsystem. These observations are from direct experience. Terry Laskodi of Tektronix
jack@mcvax.UUCP (02/25/87)
In article <395@stracs.cs.strath.ac.uk> jim@cs.strath.ac.uk writes: > >Granted MACH has lots of interesting things in it, but it is HUGE. Even >a BSD kernel pales into insignificance. I recall someone from CMU saying >that their development kernel had a 700K text segment! OK - it may have >had lots of redundant code for development work, but I can't see how MACH >could be smaller than a comparable Berkeley kernel with all these nice new >ideas that CMU are implementing. > >The MACH kernel source might be prettier, but can we afford the extra core >needed to run it? :-) > This isn't strictly true: since MACH is a distributed operating system, you can configure your systems intelligently. For instance, put all terminals on one machine, all your disks on another one, etc. I'm not too familiar with MACH, but if it follows the model of most distributed operating systems (like V or Amoeba), if will consist of a moderately-sized kernel, accompanied by a large number of huge server to provide 4.3 compatability. This should make this scheme possible. This has the big advantage that you don't have to have all servers on all machines. Admitted, it has the disadvantage that one machine going down will leave you with a perfectly running distributed system without any terminals:-) -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
henry@utzoo.UUCP (Henry Spencer) (03/01/87)
>> You should try the kernel hack on a decent system before dismissing it. > >I guess it's just the Berkeley philosophy to do things in the kernel >whenever possible, even when it's not necessary. The question is not whether it's necessary to put things in the kernel -- if one is willing to accept disastrous performance degradation, almost nothing *needs* to go in the kernel -- but whether it is appropriate to put a specific thing into the kernel. Coordinating use of resources is *the* most central role of the kernel. Virtually everything the kernel does could be done in library functions if sharing wasn't an issue. So coordinating shared use of serial ports is an eminently reasonable thing to put in the kernel, if you can make it simple and workable. You can. Speaking as someone who is strongly biased in favor of small, simple kernels, and whose hatred of many aspects of the "Berkeley philosophy" is widely known, doing dialin/out coordination in the kernel is the right thing to do. Making it work with the existing tty handler code isn't the easiest thing in the world, but the resulting user interface is so simple and beautiful that we're willing to live with slightly buggy machinery until we get around to fixing it. As testimony to the simplicity and appeal of the technique, it was invented independently in at least four different places. -- Legalize Henry Spencer @ U of Toronto Zoology freedom! {allegra,ihnp4,decvax,pyramid}!utzoo!henry
paul@vixie.UUCP (03/02/87)
In article <7717@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >As testimony to the simplicity and appeal of the technique, it was invented >independently in at least four different places. Are any of those four available to the public? I'm currently editing /etc/ttys on the fly and sending HUP signals to init -- I'd prefer to have it in the driver. I have driver source, but not kernel source. -- Paul A. Vixie {ptsfa, crash, winfree}!vixie!paul 329 Noe Street dual!ptsfa!vixie!paul@ucbvax.Berkeley.EDU San Francisco CA 94116 paul@vixie.UUCP (415) 864-7013