Date: Tue, 21 Sep 1999 19:50:37 -0600 From: Warner Losh <imp@village.org> To: Wes Peters <wes@softweyr.com> Cc: John-Mark Gurney <gurney_j@resnet.uoregon.edu>, FreeBSD Hackers List <freebsd-hackers@FreeBSD.ORG> Subject: Re: what is devfs? Message-ID: <199909220150.TAA29152@harmony.village.org> 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> <Pine.BSF.4.05.9909202321540.22714-100000@home.elischer.org> <199909212040.OAA27457@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909220150.TAA29152>