Date: Fri, 29 May 1998 22:34:47 -0700 From: Mike Smith <mike@smith.net.au> To: Greg Lehey <grog@lemis.com> 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: <199805300534.WAA00954@antipodes.cdrom.com> In-Reply-To: Your message of "Sat, 30 May 1998 15:30:46 %2B0930." <19980530153046.E20360@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > 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. The easiest way to "resurrect" a node is to simply duplicate the original from the "master". -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199805300534.WAA00954>