linux-kernel - Re: NAK new drivers without proper power management?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Feb 2007 21:22:48 -0500
From:	"Lee Revell" <rlrevell@...-job.com>
To:	nigel@...el.suspend2.net
Cc:	"Robert Hancock" <hancockr@...w.ca>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	"Jeff Garzik" <jeff@...zik.org>
Subject: Re: NAK new drivers without proper power management?

On 2/9/07, Nigel Cunningham <nigel@...el.suspend2.net> wrote:
> On Fri, 2007-02-09 at 20:59 -0500, Lee Revell wrote:
> > On 2/9/07, Robert Hancock <hancockr@...w.ca> wrote:
> > > I would disagree that it's a peripheral issue, it's pretty core these
> > > days, at least for any hardware that you can stuff in a laptop (though a
> > > fair number of desktops get suspended and resumed these days too).
> >
> > Servers are still the most important Linux market, and don't care
> > about suspend/resume.  I would consider implementing suspend./resume
> > for a driver that will only be used in server or HPC class hardware a
> > waste of valuable development resources.
>
> Not necessarily. Imagine suspending to disk in order to replace a faulty
> card. That could be way faster and less disruptive than shutting down
> normally and loosing caches and so on.
>

Hmm.  If uptime is critical I would make sure to have redundant
systems anyway and I would just reboot the thing.  I would not expect
the suspend/resume paths on server class hardware like 10gig ethernet,
Infiniband adapters, or high end SCSI to be particularly well tested.

> Irrespective of the above, servers tend not to have too much in the way
> of hardware unique to them anyway, and even if you don't find it useful,
> that's not to say others won't want it.

Yes but for such hardware, suspend/resume is likely to be a lot of
work to implement, and I'd rather the developers devote those
resources to making the driver as stable and performant as possible.

I agree 100% that drivers for desktop and laptop hardware should be
rejected if missing suspend/resume.

Lee
-
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/