DEVFS in a chroot?

[Poul-Henning Kamp]

In message <20040430.070341.26991317.imp at bsdimp.com>, "M. Warner Losh" writes:
>In message: <5473.1083327210 at critter.freebsd.dk>
>            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
>: >Should I mount /var/chroot/dev as type devfs?
>: 
>: Yes:
>: 
>: 	mount -t devfs randomargument	/var/chroot/dev
>
>What if I have hundreds of these chroots?  We build our product inside
>a chroot right now and I'm worried what the overhead of
>mounting/unmounting this for every build would be...

As far as I recall, our mountlist handling is not optimised for
hundreds of simultaneous mountpoints: we basically walk the list.
That said, I belive we only do so during the actual mount/unmount
operations, so I do not think there is a performance issue as such.

The need to mount devfs under chroot and jails is the main disadvantage
to DEVFS, but the only alternative is to tell namei(9) about "/dev"
being utterly magical and that has so many boatloads of problems that
I am not even willing to look at it (again).

Julian has proposed introducing a kind of "named VCHR" vnode, for
these cases, basically instead of "mknod null c 34 0" which addresses
the device driver by major/minor, it would be "mknod null c null"
where you address it by name.  In theory this could avoid the need
to have devfs mounted in chroot/jails where you really "only want
null, zero, console".  There are many unresolved issues with the
idea, but it might be feasible, given enough time and interest.
The fact that it will not work well for /dev/tty and not at all
for PTYs however limit the interest a lot.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.