Date: Sat, 30 May 1998 15:30:46 +0930 From: Greg Lehey <grog@lemis.com> To: Peter Wemm <peter@netplex.com.au>, "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG Subject: Creating/deleting devfs nodes (was: I see one major problem with DEVFS...) Message-ID: <19980530153046.E20360@freebie.lemis.com> In-Reply-To: <199805300511.NAA20017@spinner.netplex.com.au>; from Peter Wemm on Sat, May 30, 1998 at 01:11:29PM %2B0800 References: <17374.896500321@time.cdrom.com> <199805300511.NAA20017@spinner.netplex.com.au>
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.
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.
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?19980530153046.E20360>