From owner-cvs-all Mon Feb 16 15:06:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29341 for cvs-all-outgoing; Mon, 16 Feb 1998 15:06:30 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29238; Mon, 16 Feb 1998 15:06:06 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA20349; Mon, 16 Feb 1998 16:05:39 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA25582; Mon, 16 Feb 1998 16:05:35 -0700 Date: Mon, 16 Feb 1998 16:05:35 -0700 Message-Id: <199802162305.QAA25582@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Justin T. Gibbs" Cc: Mike Smith , "John S. Dyson" , bde@zeta.org.au (Bruce Evans), dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence In-Reply-To: <199802161829.LAA19996@pluto.plutotech.com> References: <199802161156.DAA06121@dingo.cdrom.com> <199802161829.LAA19996@pluto.plutotech.com> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > >The prototype mechanism in the current system is implemented in > >the /dev/MAKEDEV script. DEVFS as it currently stands moves this > >prototyping into the kernel, and makes it nonconfigurable. > > And most people never modify /dev/MAKEDEV. Instead, they simply chmod/ > chown devices after they are created by MAKEDEV. In a DEVFS scenario, > you have the same capabilities. Except that with MAKEDEV, you don't get to use the device until you make it, so you never have any significant point in time where the 'defaults' aren't OK. When they are created by default, you do if they aren't the same as the kernel. (Think about non-standard devices, or sound stuff that isn't 'created' by default until it's used, or better yet PCMCIA/CardBus hardware.) With MAKEDEV the user doesn't get access to the device until the administratory explicitly creates it, and when he does he will also modify the defaults if necessary for that machine. With DEVFS, no such 'safety' margin exists, since the device is created possibly with the administrator realizing it. If you provide a way to modify the 'defaults', then the administrator can be assured that things will be as open (or closed) as desired w/out having to modify the kernel sources. Not being generic enough is as bad of a problem as being too generic. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message