Date: Wed, 31 Jan 2001 17:27:05 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Warner Losh <imp@harmony.village.org> Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Message-ID: <XFMail.010131172705.jhb@FreeBSD.org> In-Reply-To: <200102010104.f1114I927261@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01-Feb-01 Warner Losh wrote: > In message <XFMail.010131162506.jhb@FreeBSD.org> John Baldwin writes: >: This is why I think ACL's for sysctl's that are administered via a sysctlfs >: wouldn't be such a bad thing. > > I think that it is significantly more difficult a problem than you > might think. The actual implementation of a sysctlfs with ACL's? It's already been written at least twice (minus the ACL's though, and determining good backing store for them that is persistent is probably the most difficulty part of that). >: However, I think that, say, hw.snd.pcm0.hwvol_mixer, is more of a hardware >: attribute then a kernel environment attribute, which >: env.hint.pcm.0.hwvol_mixer >: kind of implies. I don't see env as being a good dumping ground for >: hardware >: configuration, so I'd almost rather have devices export any important >: information via a sysctl that lives in the proper part of the sysctl tree >: rather than just stuck under env. > > I respectfully disagree. While we are using the kernel environment > for this, that's just an unimportant implementation detail. > hint.pcm.0.hwvol_mixer implies to me an attribute of unit 0 of pcm. > With the hw.snd tree, you have to look in many places for the meta > information for the device. Some stuff is in the config space, some > stuff is in the snd tree, and other stuff is who knows where. That > makes it hard to implement a generic meta information editor and > infrastructure. Well, I don't think that env.hint is any better of a dumping ground than hw. :) Both have their roots in other places, and I get the feeling you would like a logical tree tied directly to the devives, so that you would have something like: int device_get_attribute(device_t dev, const char *name, int *len, void *value); int device_set_attribute(device_t dev, const char *name, int *len, void *value); Where 'name' is the name of a node under some arbitrary tree whose immediately preceding branches are either 'foo0' or 'foo.0'. One implementation might be to create a 'devices' top-level sysctl node to stick this under. *shrug* If you allow implicit creation of attributes, then that API might be enough, so long as when a device goes away, it's entire tree goes away. Another choice might be to require explicit adding/removing of per-device attributes. You also might want to have devclass attributes (the pcm snd_unit is an example of this.) Is this what you are looking for? -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010131172705.jhb>