Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Jun 1998 23:12:53 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        mike@smith.net.au (Mike Smith)
Cc:        bag@sinbin.demos.su, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG
Subject:   Re: I see one major problem with DEVFS...
Message-ID:  <199806012312.QAA29364@usr05.primenet.com>
In-Reply-To: <199806011909.MAA00869@dingo.cdrom.com> from "Mike Smith" at Jun 1, 98 12:09:39 pm

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-).


> 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.

For normal devices that are only operated on via open/close/read/write,
it makes sens to export a devfs.  This works for printers, disks,
floppy drives, backup tapes (assuming the rewind/norewind device name
convention is maintained) and, in some cases, pty's and ttys.  The
dmesg, etc., is another obvious candidate.

This isn't as useful as the true proxy provided by OpenNET, but it's
a good step in that direction.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

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?199806012312.QAA29364>