On Sun, 11 Feb 2007, Rafael J. Wysocki wrote:
> The problem is it was made implicit long ago. The design is "optimistic", so
> to speak, and I think we have the following choices:
>
> 1) Change the design to make the kernel refuse to suspend if there are any
> drivers not explicitly flagged as "suspend/resume-safe". [This looks like a
> lot of work to me, but it is generally doable provided that someone has enough
> time to do it. Unfortunately it has to be done in one shot for all of the
> known good drivers to avoid user-observable regressions.]
The kernel wouldn't necessarily have to refuse to suspend. It could just
warn (and list the drivers that aren't marked), or could require some
extra insistance from the user. It would be good to have it log a message
saying something like: "If you can read this, report that ne2000 seems to
be safe for suspend/resume". Having drivers explicitly marked as to
whether they are safe is a good kernel feature; what to do if they're not
is policy.
> 2) Require the authors of new drivers to _either_ ensure that their drivers
> will be suspend/resume-safe (and I mean both STR and STD here), _or_ explicitly
> flag the drivers as "suspend/resume-unsafe", for example by impelenting
> .suspend() routines returning -ENOSYS. [The existing drivers can be modified
> to follow this convention gradually.]
I don't see any reason not to do (2) regardless of (1). That was (my idea
of) the statement that started this thread: new drivers need to not mess
up on suspend/resume, as a matter of suitability for inclusion. Of course,
we need some way for drivers to indicate that they work fine with the
PCI-layer defaults. And it should probably more machine-readable than the
author telling reviewers that it works.
> - Problem what to do with drivers that work for some people and don't work
> for the others (ie. if we don't flag them as known good, we will break the
> setups in which they work)
I think the only interesting case here is when a device resumes fine with
no driver support if the BIOS manages to deal effectively with it, but the
BIOS generally doesn't. Otherwise, I think it's only going to work at
all if the author put in the effort to make it work (so it should be
"known good"), but there may be bugs (firmware, BIOS, driver, etc). But
that's true of any functionality.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
