Date: Fri, 1 Jan 1999 18:55:40 -0500 (EST) From: Chuck Robey <chuckr@mat.net> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <Pine.BSF.4.05.9901011829540.335-100000@picnic.mat.net> In-Reply-To: <94808.915113237@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 31 Dec 1998, Poul-Henning Kamp wrote: Poul, that was a *great* summary. I'm not going to quote it (it's pretty big) but anyone who missed it, I have a copy and will keep it around for the length of this thread's discussion, so just mail me and ask for it. Anyhow, I want to take on two points, persistence vs. non-persistence, and default values. I know default values for things are not important if non-persistence is chosen, but since the point is raised in both the persistence and non-persistence parts of your arguments, I think I want to raise it here. First, Poul, will you agree that the opinion of the great majority of developers want persistence? I clearly remember a post from a while back, from Jordan at some convention, where he mentions being buttonholed by a number of very influential folks, all of which expressed strong pro-presistence arguments. I know that you brought up your same position at that time (you've been pretty consistent), but wasn't persistence conceded to be an absolute requirement for a DEVFS? To take it one step further, wasn't one of the main reasons for the non-acceptance of our last devfs (not the only reason, but a main reason) it's lack of a strategy for implementing persistence? [I'm trying hard not to inject any trace of sarcasm here at all, please do me the favor of giving me the benefit of doubt, if I mess up some wording and it seems like I'm being cute or something]. If anything I said above is inaccurate or you feel I'm wrong, I'd like to know. If you want, I'll even try to track down that old post from Jordan ... it's probably 2-3 years old by now. Anyhow, moving to the lack of defaults ... you claim that there is no method of restoring default values to a device, once that device has been modified in the persistence database. I disagree. While I don't agree with your statement that all modes and permissions for everything in /dev are a matter of policy, I *would* agree that default values for stuff in /dev are a matter of policy. As such, default values could very easily be handled, couldn't they, in a number of different ways, in fact. It could be done in ASCII files (RO files, not modifiable), or the drivers themselves could store such stuff, and regurgitate it on ioctl calls, right? It could even be done via sysctl, although that strikes me as a bit weird. Restoring defaults to a persistence database then wouldn't seem to be all that terribly hard. You're better at that part than I am, maybe if you made that part a little clearer, I'd see what the roadblock really is. BTW, things like links, that I couldn't deal with, I'm just talking about modes and permissions. I think that's all that needs defaults, right? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901011829540.335-100000>