Date: Wed, 31 Jan 2001 18:04:18 -0700 From: Warner Losh <imp@harmony.village.org> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/ata ata-disk.c Message-ID: <200102010104.f1114I927261@harmony.village.org> In-Reply-To: Your message of "Wed, 31 Jan 2001 16:25:06 PST." <XFMail.010131162506.jhb@FreeBSD.org> References: <XFMail.010131162506.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. : 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. : Also, for dynamic sysctl's, it is easier to : use 'pcm0' for a node than a '0' node under a 'pcm' tree. This is because : device_get_nameunit() gives us a string we can just pass to sysctl_add_oid(), : whereas device_get_unit() returns an integer that we'd have to malloc a string : for and sprintf() into or something. (I guess we could do _really_ evil things : where we return a pointer into the nameunit string that starts with the unit : number). This precludes us from having device names that end in a number. That's currnetly supported and works well, at least for loadable modules. I think that drivers have no business using sysctl directly. We need to have a good system that allows them to get hierarchical information dynamically. It may be the case that this is done with sysctl under the covers, it may not. Since it would likely be universal and easy to use, arguments about the relative ease of implementation at this level likely aren't going to be very important at all. If we enhance the device interface to allow this, it wouldn't matter how thigns were implemented. Right now kernel environment variables are a handy communication device between the loader and the kernel such that no changes were needed there. Once they are into the kernel, the way the work are an implementation detail that really should be ignored for designing a good interface for driver writers to use. I'll admit that the current interface for resource_int_value and resource_query_string are poorly documented. They also don't allow for easy setting once the probe/attach code has run. We need to fix that. I'm of the mind that we need to have a single, unified tree (maybe managed by sysctl, maybe not). That tree would then cause callbacks to the drivers to happen when the values in them change so the driver can react to them or ignore them as they happen. The sysctl tree could be used for this behind the scenes updating. Drivers could register those items that it understands. This would easily allow us to write a generic meta data editor. Warner 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?200102010104.f1114I927261>