From owner-freebsd-hackers Tue Sep 21 18:51: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 614AD150D2 for ; Tue, 21 Sep 1999 18:51:04 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA03068; Tue, 21 Sep 1999 19:51:03 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA29152; Tue, 21 Sep 1999 19:50:37 -0600 (MDT) Message-Id: <199909220150.TAA29152@harmony.village.org> To: Wes Peters Subject: Re: what is devfs? Cc: John-Mark Gurney , FreeBSD Hackers List In-reply-to: Your message of "Tue, 21 Sep 1999 17:13:13 MDT." <37E81109.E7612259@softweyr.com> References: <37E81109.E7612259@softweyr.com> <19990921000009.54622@hydrogen.fircrest.net> <19990920231629.26284@hydrogen.fircrest.net> <199909212040.OAA27457@harmony.village.org> Date: Tue, 21 Sep 1999 19:50:37 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37E81109.E7612259@softweyr.com> Wes Peters writes: : Is there any possibility of creating a database of devfs perms that gets : loaded into kernel-accessible data space by the loader before boot? Once : the system is up, devfsd could take over, monitoring and updating the : state of devfs and this database, and the perms would come up as they were : last set, modulo the cycle time of devfsd. Hmmm. That's an interesting possibility. If we could load this database from the boot loader, then we could have a good snapshot of the user's desired persistance. This would allow the kernel to have a template for the permissions as the devices are coming up... Interesting possibilities here. This sounds a lot like the notion that I've had for a while of having a Xdefaults-like database to pass parameters to device instances. This would be just another parameter... Might not even need a devfsd in a case like this, if you don't mind your /dev tree being configured in a manner that is different than in prior versions. Or in other words, why stop with just the owner, group, flags and permission bits. Why not save other things as well... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message