[ Adding "devel". ] I wrote: > All this seems to point in the direction of needing a filter complex > enough to justify a little user space library.
Any opinions on this ? I've briefly discussed the idea of having a library that combines basic kernel services in an Openmoko-specific way with Mickey on IRC today, and he likes it. The name "libmoko" would still be available. Since I'm copying to the "devel" list as well, I put the bulk of my posting below, for reference. | All this seems to point in the direction of needing a filter complex | enough to justify a little user space library. Particularly the | decision of what constitutes a plausible value isn't one the kernel | should be asked to make. | | Do we have some sort of library for such things already ? There are | many things that are better done in user space than in the kernel, | so it would be good to have a default location for them. In the | absence of such a library, people will just pick the next best | "default location" and try to put all the device-specific hacks | into the kernel. | | The API would then be a C function, not a sysfs file. It would be | extra-nice to also have some simple command-line wrapper that | comes with the library that would also let scripts and such easily | benefit from the library. | | With the filtering in the library, the kernel could just return an | error if it detects a problem, and leave the proper policy (i.e., | keep the old value, extrapolate, pass the error to the application, | etc.) to the library. - Werner
