Re: [Suspend2-devel] Re: uswsusp history lesson
From: Arjan van de Ven
Date: Sat Jul 08 2006 - 06:40:33 EST
On Sat, 2006-07-08 at 20:14 +1000, Bojan Smojver wrote:
> On Sat, 2006-07-08 at 11:11 +0200, Jan Rychter wrote:
>
> > I hate these kinds of discussions, but since no one else did, I'm going
> > to say this very openly: I don't think you should be the one "deciding"
> > this.
>
> ACK.
>
> Given that:
>
> - this tie is permanent due to fundamental design disagreements
>
> - swsusp, uswsusp and Suspend2 can coexist in the same tree
>
> - Nigel has a track record of excellent support for his code
>
> Why not make another kernel subsystem (Suspend2) and make Nigel
> maintainer of it? Then all this nonsense can stop and distributions and
> users can pick what they really want.
ok now a counter voice, and I'm sure I'm not going to be popular by
saying this:
Multiple all-half-working implementations is insane. It means bugs don't
get fixed, it means there isn't going to be ANY implementation that is
good enough for a broad audience. People will just switch to another one
rather than reporting and causing even the most simple bugs to get
fixed. What is worse, these suspend systems will inevitable have
different requirements on the rest of the kernel, and will thus
complicate the heck out of it for the rest of the developers. This in
turn will make *all* implementations more fragile, and everyone loses.
Very often, choice is good. but for something this fundamental, it is
not. We also don't have 2 scsi layers for example.
Now as to which it should be; I believe whatever happens it has to be
simple and robust. No fancy shnazy GUI inside the kernel, but SIMPLE.
Including well a defined and portable set of requirements on the kernel
and drivers, and done such that driver people who don't know the fine
details, can still get their drivers right.
Greetings,
Arjan van de Ven
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/