From owner-freebsd-current Fri May 29 23:44:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA02433 for freebsd-current-outgoing; Fri, 29 May 1998 23:44:34 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA02383 for ; Fri, 29 May 1998 23:44:24 -0700 (PDT) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id QAA20273; Sat, 30 May 1998 16:13:49 +0930 (CST) (envelope-from grog) Message-ID: <19980530161349.F20360@freebie.lemis.com> Date: Sat, 30 May 1998 16:13:49 +0930 From: Greg Lehey To: Mike Smith Cc: Peter Wemm , "Jordan K. Hubbard" , Eivind Eklund , current@FreeBSD.ORG Subject: Re: Creating/deleting devfs nodes (was: I see one major problem with DEVFS...) References: <19980530153046.E20360@freebie.lemis.com> <199805300534.WAA00954@antipodes.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199805300534.WAA00954@antipodes.cdrom.com>; from Mike Smith on Fri, May 29, 1998 at 10:34:47PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 29 May 1998 at 22:34:47 -0700, Mike Smith wrote: >> On Sat, 30 May 1998 at 13:11:29 +0800, Peter Wemm wrote: >>> For the problem at hand though, I once suggested to Julian that we use >>> undelete(2) to make files come back. "rm -W bpf4" could almost work as is, >>> except that it wants to stat the file and look for whiteout flags first and >>> 'rm' doesn't create a whiteout in devfs. (This might be an interesting >>> approach to the problem if all unlinks caused a whiteout instead of the >>> node disappearing entirely.) >> >> I don't really understand this. >> >> 1. Why should it be possible to delete a device node from devfs? It >> shouldn't be possible to remove individual nodes without removing >> their functionality. rm isn't the right tool to do that, and I'd >> consider it a bug to allow it. > > There is an argument that suggests that this can be used to enhance > security, eg. in chroot-jail duplicate devfs mounts. I think you need to be more specific. I can see a number of things that you might mean here. What's wrong with setting the permissions of the nodes? That shouldn't be impacted by devfs. >> 2. If for some reason (including explicit disabling, or unloading of >> an LKM), a device node *does* disappear, the obvious tool for >> reconstruct it is the device driver. If you need to do this, >> something akin to camcontrol's rescan function is what you need. >> In the case of an LKM device driver, the driver should always >> create its nodes when it starts. > > If a node is removed from a mounted devfs, the driver is not impacted - > it will have copies of this node in other devfs instances including > the invisible "master" instance inside the kernel. That's an assumption. The way I stated it, it would be incorrect. > The easiest way to "resurrect" a node is to simply duplicate the > original from the "master". The real question is what the device nodes are for. If they're supposed to be an accurate reflection of the device driver's capabilities (my premise), this wouldn't make sense. If they're supposed to provide access to the device driver (your apparent premise), that's fine. But then we don't really need devfs, we can use the current method. BTW, vinum creates its own device nodes when it's started. Does anybody have any comments on this? Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message