From owner-cvs-all Fri Feb 13 22:17:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA05284 for cvs-all-outgoing; Fri, 13 Feb 1998 22:17:14 -0800 (PST) (envelope-from owner-cvs-all@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 WAA05266 for ; Fri, 13 Feb 1998 22:17:10 -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 VAA18230; Fri, 13 Feb 1998 21:23:18 -0800 (PST) Message-Id: <199802140523.VAA18230@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Joao Carlos Mendes Luis cc: julian@whistle.com (Julian Elischer), mike@smith.net.au, phk@critter.freebsd.dk, committers@FreeBSD.ORG Subject: Re: devfs persistance In-reply-to: Your message of "Sat, 14 Feb 1998 02:36:35 -0200." <199802140436.CAA01747@gaia.coppe.ufrj.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 1998 21:23:17 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > Some questions about DEVFS. (Shouldn't this go to freebsd-hackers ?) > > 1) What will be the impact on hand-created devices ? Will still be possible > to simply mknod some file on some dir and use it ? Not effectively, no. > I don't like the > ideia of having to use DEVFS on chrooted environments. In such > environments not all devices should be seen, and the permissions > could be even different from the defaults. This is what we have just been discussing. We're aware of the requirement; what has been left out in your consideration? > 2) What's the practical meaning of "turning DEVFS default" ? I have no idea. > 3) Will DEVFS in any sense make major numbers random ? if so, my #1 Yes. > question is already answered. Not to hardcode device number is > good, but letting the kernel choose them on the fly is not good. Why is this? Do you have any reasoning beyond personal preference? > I like, for example, the Solaris' /etc/name_to_major approach. That's just as bad as MAKEDEV in the first place. > I still don't have an ideia of how to > get this into the DEVFS approach of keeping device file information > in kernel memory. I'm not sure I understand you here. > Being said the above, I think I like Mike Smith's approach of > /dev/devperm. But there's no need of a backing store. Just There is. > put a "cat /etc/minor_perm > /dev/devperms" right after mounting > /dev. If you want to do it this way, you can. But bear in mind that this approach has the following flaws: - you forgot /dev/devrules - if you only have one file, /etc/devperms, how can you have multiple devfs mounts with different permissions? > If you need any change, just edit the file and cat it again. No. Definitely not. devperms is for single-device overrides, and its contents will respond to chown/chmod operations to avoid violating POLA. > The file could be read to get the current configuration, but a > change into the mounted system would not reflect into it. Or maybe > the could be another device that would read the current config. > Maybe a sysctl is needed for the name_to_major approach, since it > needs to be loaded before mounting. It is likely that major numbers will disappear at some stage in the not-too-distant future. -- \\ 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 cvs-all" in the body of the message