From owner-freebsd-hackers Sun Jul 16 17:12:43 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA13824 for hackers-outgoing; Sun, 16 Jul 1995 17:12:43 -0700 Received: from mpp.minn.net (mpp.Minn.Net [204.157.201.242]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id RAA13818 for ; Sun, 16 Jul 1995 17:12:40 -0700 Received: (from mpp@localhost) by mpp.minn.net (8.6.11/8.6.9) id TAA02076; Sun, 16 Jul 1995 19:12:17 -0500 From: Mike Pritchard Message-Id: <199507170012.TAA02076@mpp.minn.net> Subject: Re: FS root mount handling discrepancy To: terry@cs.weber.edu (Terry Lambert) Date: Sun, 16 Jul 1995 19:12:16 -0500 (CDT) Cc: bde@zeta.org.au, hackers@freebsd.org In-Reply-To: <9507162325.AA17210@cs.weber.edu> from "Terry Lambert" at Jul 16, 95 05:25:21 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1273 Sender: hackers-owner@freebsd.org Precedence: bulk > Subsequent changes to the mount interface are also planned: > > o Move the file system specific mount knowledge (with the > exception of the ":" being used for remote file system > identification) OUT of the mount command and into per > file system code (still hidden under the mount command). > This finally resolves the ability to drop in file systems > at the administrator level as modules without requiring > a kernel rebuild (only a module load). To totally get off the subject of real time clocks... There is currently a problem with mount in that: mount /xyzzy /xyzzy (where /xyzzy = a directory) Panics because the mount syscall locks the directory, then calls the file system dependent mount, which does a name lookup on /xyzzy again, and namei dies trying to lock the vnode again. I didn't see a clean way to fix this, but it sounds like with the above changes, the file system specific mount would have control over both arguments. That would let it lookup the special device first, validate it, then lookup the mount point directory and lock it, thus avoiding the problem. I believe that the PR# is kern/434. Something to keep in mind. -- Mike Pritchard mpp@legarto.minn.net "Go that way. Really fast. If something gets in your way, turn"