From owner-freebsd-current Sat May 30 12:11:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA18073 for freebsd-current-outgoing; Sat, 30 May 1998 12:11:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA18068 for ; Sat, 30 May 1998 12:11:08 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id LAA10479; Sat, 30 May 1998 11:59:10 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd010476; Sat May 30 18:59:00 1998 Date: Sat, 30 May 1998 11:58:58 -0700 (PDT) From: Julian Elischer To: Peter Wemm cc: "Jordan K. Hubbard" , Eivind Eklund , current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-Reply-To: <199805300511.NAA20017@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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