From owner-freebsd-hackers Sun Jun 27 10:50: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from math.psu.edu (leibniz.math.psu.edu [146.186.130.2]) by hub.freebsd.org (Postfix) with ESMTP id 80F2714EA6 for ; Sun, 27 Jun 1999 10:50:07 -0700 (PDT) (envelope-from viro@math.psu.edu) Received: from weyl.math.psu.edu (weyl.math.psu.edu [146.186.130.226]) by math.psu.edu (8.9.3/8.9.3) with ESMTP id NAA29326; Sun, 27 Jun 1999 13:50:02 -0400 (EDT) Received: from localhost (viro@localhost) by weyl.math.psu.edu (8.9.3/8.9.3) with ESMTP id NAA02781; Sun, 27 Jun 1999 13:50:02 -0400 (EDT) X-Authentication-Warning: weyl.math.psu.edu: viro owned process doing -bs Date: Sun, 27 Jun 1999 13:50:02 -0400 (EDT) From: Alexander Viro To: der Mouse Cc: Francois-Rene Rideau , FreeBSD Hackers , NetBSD Kernel , OpenBSD Kernel , Linux Kernel Subject: Re: Improving the Unix API In-Reply-To: <199906271658.MAA22092@Twig.Rodents.Montreal.QC.CA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 27 Jun 1999, der Mouse wrote: > > Another problem was the ability to change the mount status of a partition > > from read-write to read-only or to unmounted, > > See NetBSD (and presumably other BSD) "mount -o update,rdonly" and/or > "umount -f". (Last I tried, the latter didn't work as it should, but > that's a matter of fixing bugs rather than introducing new features.) mount -o remount,ro on Linux. What was the problem? Indeed you can't do it if you have files opened for write there (or pending removal of files from unlinks), but that limitation is reasonable, IMHO. > > As for the opening with no permissions - well, it would make *big* > > sense if we could narrow down the API and move chown(), chmod(), etc. > > into libc leaving f-variants in the kernel. > > I really don't like that. The reasons why are (1) this means you have > to have an fd free to do them; (2) it triples the number of user/kernel > crossings involved. The former is not too terrible, but the latter... Yup. > > Extreme variant might include {set,get}sockopt extended to files and > > doing both *stat and *ch{mod,own,flags} via that. > > If done, I think the name should be changed. They are ?etSOCKopt, > after all. I'm not fond of this, though; it amounts to returning to > using ioctl() for the tasks - albeit with a slightly different name. The *only* way to make it reasonable would be to have a hierarchical namespace for the options. Otherwise you are just getting the ioctl() mess, and that's the last thing I'ld like to see. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message