Date: Mon, 17 Jul 2000 23:20:30 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Julian Elischer <julian@elischer.org> Cc: Robert Watson <rwatson@FreeBSD.ORG>, Warner Losh <imp@village.org>, Kelly Yancey <kbyanc@posi.net>, Dan Nelson <dnelson@emsphone.com>, Adrian Chadd <adrian@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the complete picture (Was: Re: SysctlFS) Message-ID: <4772.963868830@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 17 Jul 2000 12:00:39 PDT." <397357D7.167EB0E7@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <397357D7.167EB0E7@elischer.org>, Julian Elischer writes: >Poul-Henning has some well meaning ideas but I disagree >with him on several topics.. > >1/ jail/chroot cannot be ignored.. >see my email on cdevs using a "60 byte" major number >for a solution to this.. I'm not saying it can be ignored. I'm saying that it is not worth complicating the issue with big time. Your "symlink device node" proposal still doesn't solve the cloning problem, so it is only 1/2 a solution to what in practice is a non-problem. >2/ The root mount problem can be easily solved if you allow >the kernel to open devices by name from the devfs namespace >without first mounting the device in user space. >I did this on the code He and sos deleted and it worked just fine. No, your code still built a vnode with no backing filesystem (it had no v_mount for instance) and that still forced a lot of special case code in generic vfs functions). >> For a moment, disregard jails and rootmounts and let us just look at >> cloning. > >they cannot be ignored as thay represent a significant usage model. >many programs expect a working /dev/tty for example. But /dev/tty can just be mknod(8)'d in the jail, and it will just work as it should. >> Next, let us look at the rootfs: >> >> Today when we boot a FreeBSD system, various magic code finds and >> mounts a root filesystem from which we execute /sbin/init (and the >> rest becomes history). >> >> A part of this ha^h^hmagic, is to take a device name, and come up >> with a vnode from which we can mount it, despite the fact that we >> have no filesystems mounted which can instantiate that vnode. >> Rather hackish, all in all. > >devfs as it is now has routines to do this.. No it hasn't, the vnode still has to be magically handled because it doesn't have a mountpoint. >> Other magic code will do similar gyrations to mount a NFS root >> filesystem. > >Since you don't need a device to mount an NFS filesystem this >is not directly relevent. see later. (always read the entire message before replying :-) >> Finally, jails: >> >> The only reason there could ever be to mount a devfs in a jail >> partition is to get access to the cloning facility, mainly for >> ptys. For the /dev/null, /dev/zero etc cases, a good oldfashioned >> mknod(8) will do just fine. Remember: the main reason for devfs >> is to cater for dynamic devices, the main thing we don't want to >> see pop up in jails is dynamic devices. > >If we us a "SYMLINK-LIKE" major number replacement, >that links an on-disk device inode to the current devfs >canonical namespace, then no extra devfs's need to be mounted, >and the cloning facilities in devfs will be available >to any inode that links to a cloning device. Your "SYMLINK-LINK" proposal offers nothing that we don't already have with major/minor identification, which for all intents and purposes we will have to retain compatibility with for quite some time anyway. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4772.963868830>