Date: Mon, 01 Jun 1998 17:42:07 -0700 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> 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... Message-ID: <199806020042.RAA02307@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 01 Jun 1998 23:12:53 -0000." <199806012312.QAA29364@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806020042.RAA02307>