From owner-freebsd-current Fri May 29 22:12:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA20230 for freebsd-current-outgoing; Fri, 29 May 1998 22:12:10 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA20196 for ; Fri, 29 May 1998 22:12:01 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id NAA20017; Sat, 30 May 1998 13:11:30 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199805300511.NAA20017@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Jordan K. Hubbard" cc: Eivind Eklund , current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Fri, 29 May 1998 20:52:01 MST." <17374.896500321@time.cdrom.com> Date: Sat, 30 May 1998 13:11:29 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "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