From owner-freebsd-current Mon Jun 1 12:16:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08189 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:16:35 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08146 for ; Mon, 1 Jun 1998 12:16:23 -0700 (PDT) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA10536; Mon, 1 Jun 1998 12:07:16 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd010511; Mon Jun 1 19:07:09 1998 Message-ID: <3572FBD0.33590565@whistle.com> Date: Mon, 01 Jun 1998 12:06:56 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: "Alex G. Bulushev" CC: Eivind Eklund , sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... References: <199806010816.MAA12889@sinbin.demos.su> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG THis is the single best argument I've heard for allowing devfs type nodes on a normal fs. :-) certainly DEVFS makes the case of providing devices to chroot environments a lot more 'heavyweight' A number of things to note about this: 1/ There is a suggestion that there be a mount option that simply mounts an EMPTY devfs, which would then be populatable using some form of mknod (which uses the name to create the device and not the major/minor) 2/ one would need to do this on each reboot or login.. alternatively a single master might exist and be referenced by a nullfs mount, unless they all wanted different devices. (e.g just their own tty device) I agonised over this when trying to figure out a way of making dynamic devices. I eventually came to the conclusion that leaving devices around across reboots wa more of a security risk than recreating them to a known state on boot or when required. My guess is that each VM (virtual machine?) would either have it's devices added as it is entered by a user, (or at least checked) or at reboot time by some custom scripts (You must be doing this with custom scripts anyway.) The two missing pieces are: 1/ the ability to mount an empty devfs 2/ the ability to create a single node in it (the reason for this discussion) a workaround for the moment would be to mount a full one, and mv the devices you need to .hold, rm -rf everything else, and mv them back. julian Alex G. Bulushev wrote: > > > On Sat, May 30, 1998 at 05:02:14PM -0400, Stephane E. Potvin wrote: > > > Maybe this will seems a stupid question but why in the first place would > > > someone want to delete a device from a devfs /dev? Or put differently why is > > > not devfs append-only so someone would be able to make new links but not able > > > to delete existing devices? > > > > For use in a chroot()'ed environment. > > there are several problems with dev's in a chroot'ed enviroment, > for example a real system (we use it): > 1. about 500 chroot'ed "virtual mashines", the /dev containes only > necessary devices (tty??) for each VM (created by mknod when VM created) > 2. users fs (on main server) with VM (end /dev for each VM) mounted via nfs > on several hosts where users realy work (chroot on nfs) > 3. each VM can created or deleted while system working on main server > > and what about future of this scheme with new devfs ideas? > mount devfs for each VM on main server and hosts where users work? > and unmount devfs on each host before VM deleted? what do you mean 'server' and what do you mean by "hosts where users work"? julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message