Date: Sat, 30 May 1998 11:58:58 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Peter Wemm <peter@netplex.com.au> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Eivind Eklund <eivind@yes.no>, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... Message-ID: <Pine.BSF.3.95.980530115741.10089D-100000@current1.whistle.com> In-Reply-To: <199805300511.NAA20017@spinner.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
you may also be able to do a mount -u to refresh deleted devices though I haven't figured out all the facets of that. On Sat, 30 May 1998, Peter Wemm wrote: > "Jordan K. Hubbard" wrote: > > > > E.g. I can shoot my foot off, but I can't sew it back on. :-) > > > > > > Yes, you can. You can mount another devfs and 'mv' a device from it > > > (or at least that's the way the specs read - I don't have devfs > > > enabled right now, so I can't test). > > > > That's utterly rude. :-) > > > > I hope you're not implying that this is going to be the accepted way > > for doing this in the future as well. Non-persistence is a big enough > > violation of POLA as it is, and not even being able to do mknod(2) > > operations on a devfs to replace missing entries would be a POLA > > catastrophe. > > Remember this is merely step 1. The Plan is to eventually replace minor/ > major devices completely so that the filesystem interface will probably be > through a 32 bit vnode pointer or something along those lines. Doing a > mknod will be practically impossible. (This has some major benefits but > will be a major change in the driver/kernel/fs interface. Drivers won't > have a major/minor number anymore, they'll just have a unit number.. > specfs will either be gone or won't resemble anything like it does now, > and will probably hang off devfs instead. > > 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.) > > > - Jordan > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > Cheers, > -Peter > -- > Peter Wemm <peter@netplex.com.au> Netplex Consulting > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > 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?Pine.BSF.3.95.980530115741.10089D-100000>