From owner-freebsd-current Fri May 29 23:40:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA01846 for freebsd-current-outgoing; Fri, 29 May 1998 23:40:07 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles135.castles.com [208.214.165.135]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA01841 for ; Fri, 29 May 1998 23:40:03 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id WAA00954; Fri, 29 May 1998 22:34:47 -0700 (PDT) Message-Id: <199805300534.WAA00954@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Greg Lehey 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...) In-reply-to: Your message of "Sat, 30 May 1998 15:30:46 +0930." <19980530153046.E20360@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 May 1998 22:34:47 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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