From owner-freebsd-stable Sun Mar 15 15:31:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA01256 for freebsd-stable-outgoing; Sun, 15 Mar 1998 15:31:31 -0800 (PST) (envelope-from owner-freebsd-stable@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 PAA01251 for ; Sun, 15 Mar 1998 15:31:26 -0800 (PST) (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 PAA12471; Sun, 15 Mar 1998 15:27:34 -0800 (PST) Message-Id: <199803152327.PAA12471@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Robert Watson cc: Mike Smith , Cy Schubert - ITSD Open Systems Group , gkshenaut@ucdavis.edu, stable@FreeBSD.ORG Subject: Re: DEVFS (was Re: More problems with new slice code ) In-reply-to: Your message of "Sun, 15 Mar 1998 18:12:16 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Mar 1998 15:27:33 -0800 From: Mike Smith Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk > On Sun, 15 Mar 1998, Mike Smith wrote: > > Having said that, it will indeed be possible to have device nodes > > appear in more than one place, and have different permissions etc. in > > those separate places, which is I think what you are getting at > > (chrooted environments, etc.) > > This is, indeed, what I had in mind -- it might be desirable to have a > chroot'd daemon have access to a device. I was also wondering about > NFS-exported devices, but with a devfs that is not really an issue. There are a lot of useful things for which having a partially or fully-populated dev directory in a chroot environment is essential. NFS-exported devices are actually problematic with a number of systems just now where non-BSD hosts can't provide device major/minor numbers of adequate size. > > If you're interested in getting a taste of this (and providing valuable > > feedback early in the picture), there are patches for -current which > > impement large portions of this already. See > > http://www.freebsd.org/~julian for more. > > I may give that a try on one of our -current test machines in a week or > so -- the -current Coda port is underway, and seeing how /dev/cfs0 (the > coda device for Vice<->Kernel communication) behaves dynamically would be > useful. Thanks for the information; this sounds like a great feature for > reducing administrative load and preventing nasties :). That's the general idea. 8) It would be extremely good to have third-party developers that think that this may interact with their product looking at the basic ideas now, to make sure that we take your concerns into account at a stage where we can still make major changes. -- \\ 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-stable" in the body of the message