From owner-freebsd-hackers Sun Jun 27 16:34:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Twig.Rodents.Montreal.QC.CA (Twig.Rodents.Montreal.QC.CA [132.206.78.3]) by hub.freebsd.org (Postfix) with ESMTP id 02A0114E84 for ; Sun, 27 Jun 1999 16:34:04 -0700 (PDT) (envelope-from mouse@Twig.Rodents.Montreal.QC.CA) Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id TAA23042; Sun, 27 Jun 1999 19:33:32 -0400 (EDT) Date: Sun, 27 Jun 1999 19:33:32 -0400 (EDT) From: der Mouse Message-Id: <199906272333.TAA23042@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: Francois-Rene Rideau , FreeBSD Hackers , NetBSD Kernel , OpenBSD Kernel , Linux Kernel Subject: Re: Improving the Unix API Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> (clri didn't work?) > Never heard about clri (was under Linux). May not have existed, then, which *would* explain it. :-) >>> 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". > If you re-read the original message, the problem is what to do about > processes with open file descriptors on the partition: stop them at > once? stop them at first file access? block them instead? kill them? Yes, that's the most difficult part. The NetBSD manpage doesn't say what happens if you "mount -o update,force,rdonly" when there are writeable descriptors open onto the filesystem, and then try to use those fds. I would assume further attempts to write would produce errors (EROFS?), unless of course the filesystem has been re-remounted read/write. The manpage for umount says -f The filesystem is forcibly unmounted. Active special devices continue to work, but all other files return errors if further accesses are attempted. I haven't looked at the relevant kernel code to see what *really* happens. > How will you allow for such large table-walking to be compatible with > real-time kernel response? *What* large table-walking? All this means you have to do is have every write check the relevant mount point to see if it's mounted read-only, for downgrading remounts, and mark the filesystem as gone, for forced unmounts. (I suspect this is what deadfs is for.) >>> I intend to put free unices in competition [...] >> Reasonable as this sounds, I think the last thing we need is yet >> another ground on which one free-unix can be doing the "nana nana >> boo boo" taunt at another. > Competition is _not_ about taunting each other for pride; I know this. I even think most of the people involved know it. But there seem to be a few - not many, but very poisonous - who seem to take any competition - indeed, almost any *difference* - as an opportunity for "we're better than you" egoboo. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message