On Mon, 29 Apr 2013, John Stultz wrote:On 04/25/2013 01:31 PM, Thomas Gleixner wrote:No. The thing is that I only prevent unbinding if it is used as theWith the module refcount held for the current clocksource there is noSo.. if the clocksource you want to unbind is the highest rated continuous
way to unload the module.
Provide a sysfs interface which allows to unbind the clocksource. One
could argue that the clocksource override could be (ab)used to do so,
but the clocksource override cannot be used from the kernel itself,
while an unbind function can be used to programmatically check whether
a clocksource can be shutdown or not.
The unbind functionality uses the new skip current feature of
clocksource_select and verifies that a fallback clocksource has been
installed. If the clocksource which should be unbound is the current
clocksource and no fallback can be found, unbind returns -EBUSY.
This does not support the unbinding of a clocksource which is used as
the watchdog clocksource. No point in fostering crappy hardware.
clocksource that doesn't need a watchdog (basically what's likely to be in-use
and required to be unbinded), its likely to be selected as the watchdog
already.
ie: on a system that has only HPET/ACPI_PM, you can't unbind HPET, since its a
watchdog.
watchdog. In the above HPET/PM scenario both are potential watchdogs,
but w/o a user it's valid to unbind one of them.
What I need to prevent is:
TSC is current clocksource and we only have ACPI_PM as watchdog and
its used. So now you try to unbind ACPI_PM then the TSC would be left
w/o a watchdog instance. That's what I'm preventing. Will reword the
changelog accordingly.