Date: Sun, 31 May 1998 21:39:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter@netplex.com.au (Peter Wemm) Cc: jkh@time.cdrom.com, eivind@yes.no, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... Message-ID: <199805312139.OAA15254@usr06.primenet.com> In-Reply-To: <199805300511.NAA20017@spinner.netplex.com.au> from "Peter Wemm" at May 30, 98 01:11:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Exactly. > Doing a mknod will be practically impossible. It was my understanding that it would be completely 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.. More specifically structurally... struct fileops goes away. > specfs will either be gone or won't resemble anything like it does now, > and will probably hang off devfs instead. It'll be gone. The point of having a specfs is to allow the creation of device nodes on (potentially) non-FFS file systems, such as NFS. Currently, it is impossible to use device nodes over NFS mounts to very nearly any non-FreeBSD machine because of the number of major and minor bits exceeding the capability of the boot host. The DEVFS solves this problem, and at the same time makes it much easier to bring up a FreeBSD port to another architecture, by allowing a working environment without any local-media FS's. > 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.) This would be useful for devices which you allow to come back; one might question why you made them go away in the first place, however. The model is more fuzzy for things like PnP device arrival on a copy of a template FS. When I plug in my Flash-RAM card, does it become visibile in the chroot environment? I'd say "no". In my mind, the simpler the security model, and the fewer exceptions, the better. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199805312139.OAA15254>