From owner-cvs-all Fri Feb 13 16:41:10 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18903 for cvs-all-outgoing; Fri, 13 Feb 1998 16:41:10 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA18886 for ; Fri, 13 Feb 1998 16:41:04 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id QAA05703; Fri, 13 Feb 1998 16:36:27 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd005699; Fri Feb 13 16:36:24 1998 Date: Fri, 13 Feb 1998 16:32:36 -0800 (PST) From: Julian Elischer To: Mike Smith cc: Poul-Henning Kamp , committers@FreeBSD.ORG Subject: Re: wfd block major number reassignment from 24 to 1 In-Reply-To: <199802140018.QAA05385@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 1/ see my response to justin. On Fri, 13 Feb 1998, Mike Smith wrote: > > Which is the right thing to do, I may not even want all the devices > > to come across... > > Sure. I agree entirely. > > Count the lines, and the breaks in paradigm, between what you suggest I > want and what you want. Your desire is for a more complicated, > inconsistent, non-extensible technique. That's Bad. I would like to point out that poul's method is not longer.. he is just showing two different cases. Mike, there is no 'consistant' manner of handling new unexpected devices, except to not show them.. or to give them some default permission (not show them would be a special case of this really). an example.. I use 24 ptys. I hav egiven them perms.. one day I user 25. (ptys are probably going to become dynamic) what does it do for the 25th?. there are a few options: 1/ sysctl -w hw/devices/ptys/perms=577 sysctl -w hw/devices/ptys/owner=root.wheel 2/ echo "pty* perm=577 owner=root.wheel" >> /etc/devperms /sbin/devdaemon& (the devdaemon would be notified of arrival events) my scheme for adding unionfs like characteristics to devfs would give semantics similar to what we have now, but not solve the problem given above. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message