Date: Wed, 3 Jun 1998 13:15:14 +0400 (MSD) From: bag@sinbin.demos.su (Alex G. Bulushev) To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, mike@smith.net.au, eivind@yes.no, sepotvin@videotron.ca, current@FreeBSD.ORG Subject: Re: I see one major problem with DEVFS... Message-ID: <199806030915.NAA15706@sinbin.demos.su> In-Reply-To: <199806020042.RAA02307@dingo.cdrom.com> from "Mike Smith" at "Jun 1, 98 05:42:07 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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.
results desired by original poster:
on nfs server we have:
{nfs_srv}# cat /etc/exports
/mnt/roots -maproot=0:0 nfs_clnt1 nfs_clnt2 nfs_clnt3 nfs_clnt4
{nfs_srv}# ls -al /mnt/roots/VM1/dev/null
crw-rw-rw- 1 root weel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null
{nfs_srv}#
on nfs client we have:
{nfs_clnt1}# mount
/dev/sd0s1a on / (local, noatime, writes: sync 6436172 async 3495235))
procfs on /proc (local)
nfs_srv:/mnt/roots on /mnt/roots
{nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null
crw-rw-rw- 1 root weel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null
^^^^^^^^^^^ time from nfs_srv
{nfs_clnt1}# ls -al /dev/null
crw-rw-rw- 1 root wheel 2, 2 3 jun 12:39 /dev/null
^^^^^^^^^^^ local /dev/null time
{nfs_clnt1}# chroot /mnt/roots/VM1 /bin/cat /etc/passwd > /dev/null
^^^^^^^^ use /dev/null in chroot environment on nfs
{nfs_clnt1}# ls -al /mnt/roots/VM1/dev/null
crw-rw-rw- 1 root wheel 2, 2 3 jun 12:25 /mnt/roots/VM1/dev/null
^^^^^^^^^^^ remote time not changed
{nfs_clnt1}# ls -al /dev/null
crw-rw-rw- 1 root wheel 2, 2 3 jun 12:40 /dev/null
^^^^^^^^^^^ local time changed
{nfs_clnt1}#
so we use "nfs mounted devices" localy on nfs clients
surely local major/minor for devices mast by the same as on the remote server
or u mast use device proxy on fs level (not existing now)
with "classic" device nodes on file systems it is realy simple
to use this scheme
with dynamic device id and devices only on devfs mounted, it is very hard
to use devices on nfs, especially if u have several nfs clients vith handreds
of chrooted "virtual mashines", a lot of mount/unmont devfs and rm/mknod in
boot time and before/after of delete/create each VM and on each nfs
server/client kill u system and require a number of custom scripts and
sync of all manipulation via network (using rsh or other tools)
>
> > 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
>
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?199806030915.NAA15706>