Date:	Sun, 11 Feb 2007 07:46:36 +0100
From:	Willy Tarreau <w@....eu>
To:	Nigel Cunningham <nigel@...el.suspend2.net>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Pavel Machek <pavel@....cz>,
	Arjan van de Ven <arjan@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, tilman@...p.cc
Subject: Re: NAK new drivers without proper power management?

Hi Nigel,

On Sun, Feb 11, 2007 at 09:37:06AM +1100, Nigel Cunningham wrote:
> On Sat, 2007-02-10 at 23:20 +0100, Rafael J. Wysocki wrote:
(...)
> > What about this:
> > 
> > "If the device requires that, implement .suspend and .resume or at least
> > define .suspend that will always return -ENOSYS (then people will know they
> > have to unload the driver before the suspend).  Similarly, if you aren't sure
> > whether or not the device requires .suspend and .resume, define .suspend that
> > will always return -ENOSYS."
> 
> If your device requires power management, and you know it requires power
> management, why not just implement power management? Doing -ENOSYS
> instead is like saying -ESPAMMEBECAUSEIMLAZY.

No, it means "Not implemented because I don't want to screw that driver with
something I'm not expert in". And it also means "Other people will quickly
notice it and will know how to fix this if they really need it".

> Let me put it another way: People keep talking about Linux being ready
> for the desktop. To me at least (but I dare say for lots of other people
> too), being ready for the desktop means that things just work, without
> having to recompile kernels or bug driver authors or wait twelve
> months. 

It's *one* usage of Linux. For this usage, you could also suggest to stop
supporting UP kernels and always build everything with SMP enabled since
more and more often, people will use multi-core systems. It will exempt
the users from upgrading their kernels when they replace their CPU. We
could also try to chase down all the drivers which do not correctly behave
when the CPU switches to a lower frequency.

> And it means that doing a bare minimum isn't enough. We keep claiming
> that Open Source is better than Proprietary software. If we accept
> half-pie jobs of implementing support for anything - driver power
> management support or hibernation support or whatever - as 'good
> enough', we're undercutting that argument. Linux's power management
> support should - as far as we're able - be at least as good as that
> other operating system's and preferably way, way better.
> 
> -ENOSYS is just not acceptable.

Nigel, don't take it as a personal offense, but I think it is a very
centric view of Linux usages. Where I work, Linux is used a lot on
servers and appliances. It is used for mail relays, HTTP proxies,
anti-viruses, firewalls, routers, load balancers, UTM, SSH relays,
etc... Nobody would ever want to enable power management on those
machines, let alone suspend which would cause a major havoc, would
the system decide to enter suspend for any reason.

Many people also have Linux on their notebooks, but as a dual-boot. You
read the word ? "dual-boot". It means that they cleanly shutdown their
system every time they don't use it anymore, and they won't know what
OS they'll use next time.

I've never heard anyone there complaining "oh, I'm fed up with this
boring boot, I always have to wait 30 seconds when I need to do
something, I wish I could suspend and resume". It is considered the
normal way of using their PCs.

So globally, those hundreds of notebooks, workstations and servers
will not be customers of the suspend code any time soon. It would
be a shame to deprive them from working drivers. You must just
accept that a lot of people are not interested in your work. It's
the same for all of us here. I know that a lot of people are not
interested in 2.4 anymore and I'm perfectly fine with that. I'm
not asking 2.6 driver authors to ensure that their driver is easy
to backport for instance.

What I really think would be a clean solution would be sort of
a capability. Either the driver *is* suspend/resume-capable, and
the system can be suspended. Or it is not, and the system must
refuse to suspend. It should not be a problem to proceed like
this because drivers which will not support suspend will mainly
be those which will not have to. And if a user occasionnaly
complains that one driver does not support it, at least you will
have a good argument against its author to implement suspend.

Best regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists