From owner-freebsd-current Mon Jun 1 18:50:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA04629 for freebsd-current-outgoing; Mon, 1 Jun 1998 18:50:02 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA04598 for ; Mon, 1 Jun 1998 18:49:38 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA02307; Mon, 1 Jun 1998 17:42:07 -0700 (PDT) Message-Id: <199806020042.RAA02307@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), bag@sinbin.demos.su, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... In-reply-to: Your message of "Mon, 01 Jun 1998 23:12:53 -0000." <199806012312.QAA29364@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jun 1998 17:42:07 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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? > > > > That's the most logical way of doing it. It would be quite > > straightforward to mount a DEVFS and have it not populated by default > > (eg. mount -t devfs -o empty ...). Then your mknods run as "normal" > > creating the devices you want. > > Since it's the same space, you could hard link from your devfs into > the empty one to create the nodes. > > This is even better, since it allows a chroot in a chroot to never > inherit more than the parent. 8-). However it is problematic to link outside of a chroot, and it may not always be desirable to be so fancy (eg. when using chroot for engineering rather than security reasons). > > DEVFS is per-system. You cannot export a DEVFS via NFS (it makes no > > sense to do so - devices there are only relevant to the host system). > > This is a deficiency in NFS, not anything else, in that it can't > proxy ioctl's via descriptor. A VFS proxy layer (as described in > Heidemann's thesis, in fact) *could* proxy this data. No, it's a direct feature of DEVFS, or more particularly to achieve the results desired by the original poster you cannot use an NFS-mounted devfs. > For normal devices that are only operated on via open/close/read/write, > it makes sens to export a devfs. No, it does not. There is no identifying information exported with a DEVFS node that allows the local system to correctly connect a node from a remote DEVFS (which may not map to a local driver) to a local device. > This isn't as useful as the true proxy provided by OpenNET, but it's > a good step in that direction. You want to proxy device accesses to devices on the exporting system. That's a completely different kettle of fish entirely. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message