Date: Fri, 30 Apr 2004 07:54:48 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: DEVFS in a chroot? Message-ID: <20040430.075448.70646001.imp@bsdimp.com> In-Reply-To: <6695.1083331489@critter.freebsd.dk> References: <20040430.070341.26991317.imp@bsdimp.com> <6695.1083331489@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <6695.1083331489@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: In message <20040430.070341.26991317.imp@bsdimp.com>, "M. Warner Losh" writes:
: >In message: <5473.1083327210@critter.freebsd.dk>
: > "Poul-Henning Kamp" <phk@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.
Would the performance issues be mitigated by mounting/unmounting devfs
all the time? Eg, only mount it while it is actively being used?
Also, the devices that the chroot needs to access are best
characterized as simple: null, random, tty. It looks like most of the
issues can be delt with, but like you say, there appear to be problems
with things like /dev/tty. One alternative would be to tar up /dev
and extract it into the chroot. However, this appears to have
problems with /dev/tty being wrong for users on other ttys. I've not
yet investigated the problems that might accrue with things like ptys
and people doing a chroot outside of the build system.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040430.075448.70646001.imp>