Jarod Wilson wrote :
> A possible solution for "on demand" services would be
:
> - If the service is disabled, never run it.
> - If the service is enabled :
> - If the relevant hardware is present, start the service
> - If the relevant hardware isn't present, skip starting the service
Essentially what cpuspeed does now.
Yup. It's doing the right thing, alright! :-)
> Then once all the hooks are present to be able to start/stop
services
> upon hot (un)plugging devices, start/stop the service when detecting
> the device's addition or removal, if the service is enabled.
>
> That way we can keep useful services "enabled" by default, although
> they'll only actually run if/when the relevant devices are detected.
> And we still leave experienced users a way to completely disable
> services they wouldn't want running for whatever reason.
Would certainly be very cool for stuff like bluetooth support. Not
relevant in the cpuspeed case (not saying that you were saying it was,
just making sure we're making this distinction). Well, I guess it
*could* be relevant if you wanted frequency scaling to start up
automagically after you manually load up a module, such as acpi-cpufreq,
and the necessary support is suddenly there, but that sounds like a
suboptimal way to do things in this particular case...
I was definitely thinking about things like bluetooth, smartcards etc.
which aren't useful for many users, but need to "just work" for all the
others.
Matthias
--
Clean custom Red Hat Linux rpm packages :
http://freshrpms.net/
Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6
Load : 0.31 0.34 0.36