Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Jun 1999 13:50:02 -0400 (EDT)
From:      Alexander Viro <viro@math.psu.edu>
To:        der Mouse <mouse@Rodents.Montreal.QC.CA>
Cc:        Francois-Rene Rideau <fare@tunes.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, NetBSD Kernel <tech-kern@netbsd.org>, OpenBSD Kernel <openbsd-tech@openbsd.org>, Linux Kernel <linux-kernel@vger.rutgers.edu>
Subject:   Re: Improving the Unix API
Message-ID:  <Pine.GSO.4.10.9906271341200.24019-100000@weyl.math.psu.edu>
In-Reply-To: <199906271658.MAA22092@Twig.Rodents.Montreal.QC.CA>

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.9906271341200.24019-100000>