Date: Sat, 30 May 1998 16:13:49 +0930 From: Greg Lehey <grog@lemis.com> To: Mike Smith <mike@smith.net.au> Cc: Peter Wemm <peter@netplex.com.au>, "Jordan K. Hubbard" <jkh@time.cdrom.com>, Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG Subject: Re: Creating/deleting devfs nodes (was: I see one major problem with DEVFS...) Message-ID: <19980530161349.F20360@freebie.lemis.com> In-Reply-To: <199805300534.WAA00954@antipodes.cdrom.com>; from Mike Smith on Fri, May 29, 1998 at 10:34:47PM -0700 References: <19980530153046.E20360@freebie.lemis.com> <199805300534.WAA00954@antipodes.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980530161349.F20360>