linux-kernel - Re: [RFD] Automatic suspend

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 2 Mar 2009 00:08:30 +0100
From:	Pavel Machek <pavel@....cz>
To:	Arve Hj?nnev?g <arve@...roid.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alan Stern <stern@...land.harvard.edu>,
	"Woodruff, Richard" <r-woodruff2@...com>,
	Arjan van de Ven <arjan@...radead.org>,
	Kyle Moffett <kyle@...fetthome.net>,
	Oliver Neukum <oliver@...kum.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	pm list <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Nigel Cunningham <nigel@...el.suspend2.net>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	mark gross <mgross@...ux.intel.com>,
	Uli Luckas <u.luckas@...d.de>,
	Igor Stoppa <igor.stoppa@...ia.com>,
	Brian Swetland <swetland@...gle.com>,
	Len Brown <lenb@...nel.org>
Subject: Re: [RFD] Automatic suspend

Hi!

> >> > I do realize that you consider your current solution as the best thing since
> >> > the sliced bread, but please accept the fact that the other people think
> >> > differently.
> >>
> >> I certainly do not think my current solution is the best, it is very
> >> invasive. I do however think your proposed solution is worse. The only
> >> proposed alternative that we could actually ship a product on today is
> >> to not use suspend at all.
> >
> > Well, I'm sure your code is useful for the Android platform, but the question
> > is whether we want this code in the mainline kernel.  For now, the answer is
> > "no, we don't".  Moreover, since you're the one who wants the code to be
> > merged, it's your burden to make it acceptable for us.  However you're going
> > to do it is up to you, but certainly trying to force your current code on us
> > is not going to work.
> 
> I don't think I am the only one who want this code in the mainline
> kernel. Many people want to use the android platform, and support in
> the mainline kernel would be beneficial to some of them. I made many
> requested changes to my code that provides no benefit to us, but I
> have not made any changes that breaks our own use.

No, you are not the only one. OTOH... that can't be used as an
argument to get it into kernel "as is".

Yes, I'd like to see it in but yes, I understand and agree with (most)
Rafaels's concerns.

> > BTW, I think you handled the thing wrong.  If I were you, I wouldn't even try
> > to push the code as you did.  I would instead make it as simple as reasonably
> > possible so that the basic idea was clear and understandable to everyone.
> > Then, if there were any doubts with respect to the basic idea, I'd try to
> > clarify them and I'd consider modifying the code to address objections.
> > I'd only try to add more features after the basic idea had been accepted.
> 
> The basic concept was developed long before android was a public project.

That's not our fault... 
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/