Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!mtune!codas!novavax!murphy!dave From: dave@murphy.UUCP (Dave Cornutt) Newsgroups: comp.unix.wizards Subject: Re: Symbolic Links Message-ID: <599@murphy.UUCP> Date: Fri, 4-Sep-87 09:22:01 EDT Article-I.D.: murphy.599 Posted: Fri Sep 4 09:22:01 1987 Date-Received: Sat, 5-Sep-87 21:35:26 EDT References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com> <1781@munnari.oz> <6366@brl-smoke.ARPA> Organization: Gould CSD, Fort Lauderdale, FL Lines: 78 Summary: a plea for peace In article <6366@brl-smoke.ARPA>, gwyn@brl-smoke.UUCP writes: > In article <586@murphy.UUCP> dave@murphy.UUCP (Dave Cornutt) writes: > >Do it on a per-process basis... > > As one of the principal developers of dual-universe UNIXes, > perhaps it is appropriate for me to comment on this. Dual > interpretations are a pain in the donkey! Select a general > enough interpretation and stick with it; don't make anything > that doesn't have to be, dependent on user whims. I'm trying to suggest a way that David Korn's scheme could be implemented in SYSV in such a way that it would be compatible with existing imple- mentations of symbolic links. (I don't see what dual-universe setups have to do with it.) > example of the dangers, consider the attempt Berkeley made > to cater to non-restart of slow I/O system calls after return > from a signal handler in 4.3BSD as originally distributed. > The bit SV_INTERRUPT in the sv_flags of the struct sigvec > was supposed to control this behavior. Unfortunately, it > was not reset upon an exec(), so if ANY process enabled > non-restart, all descendants acted that way too. Of course, > the descendant processes were written assuming the default > 4.3BSD restart of system calls, so things like our EMACS > editor broke horribly when run from a System V shell. The > moral is, too many options on how the OS behaves is a hazard. Then I guess we should get rid of all those pesky tty mode bits and go back to just CBREAK and RAW. If we get rid of all options that can modify the behavior of the OS, then we have a pretty inflexible system, and that just doesn't seem to be in the spirit of UNIX. Of course, haphazard implementation of options can lead to its own set of problems, especially when the default is not defined or not compatible with previous behavior. In the case above, not resetting the SV_INTERRUPT flag on exec could be regarded as a design botch since the default state after an exec is undefined, and it directly affects the way certain things in the program may behave. Actually, the thing that should have been done originally, way back in the beginnings of BSD, was to make the V7 behavior the default and provide some way of setting a flag on a per-process basis to get the auto-restart character- istic. But hindsight is easy. The ".." thing is more of a per-session characteristic. A user either wants all processes that he/she runs to interpret ".." as "up", or none of them. Unfortunately, the UNIX kernel does not maintain any per-user or per- session information (execpt for disk quotas and a few things in the tty driver), so you have to simulate it by carrying things over from parent to child processes. There is precedent for this; consider the resource limits in BSD. That's why I suggested inheriting the setting of the flag on exec. Since it doesn't directly affect the call and return conventions of any system calls, I think it would be reasonably safe. I'll have to admit that I'm not all that comfortable with something that can be flipped on and off that can change the interpretation of file names. I'm just trying to come up with an idea so that we can have our cake and eat it too: the Korn idea, but with compatibility (by default) with existing behavior. Since the only existing behavior is the BSD one, that has to be the default. (I'll admit that there are some political problems with asking SYSV to adopt a BSD idea.) This certainly isn't the only way to do it; someone else (sorry, but I can't find the article) suggested making ",," mean "up", which would be fine with most people. On the other hand, the idea of just imposing Korn's scheme without giving any alternative would not fly with our customers at all. Since both behaviors appear to have a substantial number of advocates, I'm trying to suggest a way that it could be implemented while allowing SYSV and BSD to move torward a common ground, instead of creating another breach. Maybe that's too much to ask for. --- "I dare you to play this record" -- Ebn-Ozn Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL [Ignore header, mail to these addresses] UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt ARPA: dcornutt@gswd-vms.arpa "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."