Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!sun!gorodish!guy From: guy@gorodish.UUCP Newsgroups: comp.bugs.sys5 Subject: Re: Unlinking "." Message-ID: <16519@sun.uucp> Date: Fri, 10-Apr-87 13:40:20 EST Article-I.D.: sun.16519 Posted: Fri Apr 10 13:40:20 1987 Date-Received: Sat, 11-Apr-87 19:46:15 EST References: <1059@cci632.UUCP> <5715@brl-smoke.ARPA> <736@killer.UUCP> <16186@sun.uucp> <753@killer.UUCP> Sender: news@sun.uucp Reply-To: guy@sun.UUCP (Guy Harris) Organization: Sun Microsystems, Mountain View Lines: 93 Keywords: unlink >Of course, the system calls are always resident and taking up some of that >not-so-plentiful-on-all-machines memory. OK, please give numbers indicating the performance cost of putting "mkdir" and "rmdir" into the system. >I haven't looked at the documentation for S5R3 yet, so I really don't know >what I am talking about here. It seems that you can always spawn a mkdir(1) >or rmdir(1) sub-process to create/delete your directories, but if the >mkdir(2) and rmdir(2) require you to be root in the first place They don't require you to be "root"; please read the documentation first. >(can you imagine > void crash () > { > for (;;) { > mkdir ("a"); > chdir ("a"); > } > } >as you favorite subroutine? :-) So what? I can think of lots of things that can hang a system up. This is hardly any sort of argument against making "mkdir" a system call. >Nice argument. I would not like to work on a system with more than one >or two different types of file systems. I have a hard enough time fixing >broken file systems as it is without having to learn another new one. Other people either want to or need to work on a system with multiple file system types. The fact that *you* wouldn't like to work on such a system doesn't mean such systems shouldn't exist. >As for the Sun systems you work on, many of the features you are adding >are not used by developers because of the differences between V7, BSDxxx >and USG Systems III, IV and V. If you would like some proof of this, >talk with some at Uniplex Integration Systems. The applications they >develope are written to use the minimal subset of features from all Unix >versions. Some developers *do* use those features. There's a tradeoff between using various not-available-in-systems-released-prior-to-1980 features (which makes your code more portable, but can reduce its performance, reliability, or functionality) and using them. In some cases it may be better to say "sorry, we won't support this program under V7". >It is possible to fix the races in the kernel without adding the calls. But is it possible to fix the *other* problems caused by the absence of those calls except by adding them? >And as for making the system fatter, when I was installing USG 4.0 on >a PDP-11/45 about 5 or 6 years ago, the system almost didn't fit because >it had gotten so fat. When USG 5.0 came out in 81 or 82, it didn't fit >because there was so much junk in it. As more stuff is added, it gets >harder and harder to cram Unix into the limited memory that many of these >machines have. So? It'd be hard to run even V6 on an 8K PDP-8. Memory is getting cheaper; sometimes you can use up more memory and get real benefits from it. >This is getting a bit ridiculous. A bold statement, made with no apparent justification. What is the dividing line between a ridiculous and a sensible kernel size? What is a criterion that can be used for deciding which features "belong" and which don't? Do you want a hard limit on the kernel size, which should apply from the time it's imposed until the heat-death of the universe? >There used to be one way to do everything in Unix. And that was picked >to be the most flexible one possible. I guess times have changed. Yes, times have changed. The new solution - "mkdir" and "rmdir" system calls - now offers more *useful* flexibility than the old solution, given the existence of multiple file system types. >I don't know if you paid any attention to the discussion about trashed file >names, but it seems to me that a system call that won't let you unlink a >directory with file entries in it is going to prevent the usual fix to this >problem - unlink the directory and run fsck(1). The *correct* fix to this problem is to have "fsck" treat directory entries containing names with embedded NUL characters as being scrambled directory entries, blast those entries, and then if necessary put entries in "lost+found" for the files referred to those entries. The fact that the "usual" fix requires you to unlink directories is irrelevant here.