Re: scheduler support to lock user processes out?

[Matthias Drochner <M.Drochner%fz-juelich.de@localhost>]

dyoung%pobox.com@localhost said:
> I can show several examples why it is not a technical requirement. :-)
> I routinely suspend several devices that are in-use, including
> ethernet & WLAN NICs, and I have even suspended the HDD where root is
> mounted. 

Imo this is by some luck, likely helped by KERNEL_LOCK which
protects all network code in particular.

Imagine a driver function called in user context, which blocks
in-kernel, waiting for something, tsleep or mutex or whatever.
Now the user suspends the device, which causes register accesses
deliver nonsense, or worse.
Even if the device was shut down properly in the suspend function,
the blocking function might awake. Spurious wakeups can occur,
or in case of a wait for malloc(WAITOK) it is obvious that it
can happen anytime.
This means that drivers would have to check after each call
which might block whether the device is still usable. Or
implement a per-device lock, which even FreeBSD has only done
for a subset of their drivers. I wouldn't consider that realistic.

We also should think about a set of features which can be
supported reasonably before NetBSD-4.99.99 is reached...
Imo, system sleep is mandatory. Suspending individual devices
on user request is not.

> I am not sure we are understanding each other.  I think that if it
> is not acceptable to you that devices should suspend while userland
> keeps running, then you may need to apply a different policy than I do.

I believe I was understanding you... Imo device suspend can safely be
done while userland is running, as long as userland (or "ifconfig up",
for that matter) has not opened the device, with manageable efforts.
Everything beyond would need considerable work on all drivers, and
would cost cycles at runtime.
Not to say that "drvctl -S" was useless, but I wouldn't advertize
that it can suspend any device anytime. What would be the use,
besides driver testing? For power management, we'd want a more
fine-grained API anyway, and for hot-plug support we generally
need explicite bus support.

best regards
Matthias




-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich

Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDir'in Baerbel Brumme-Bothe
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt,
Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------