From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 3 Feb 2006 11:55:19 +0500 From: Andrey Rahmatullin To: ALT Linux kernel packages development Message-ID: <20060203065519.GA24501@wrars-comp.wrarsdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline X-Operating-System: ALT Linux Sisyphus User-Agent: Mutt/1.5.11 X-Spam-Status: Unsure, tests=bogofilter, spamicity=0.672778, IP:212.23.82.111 X-Sagator-Scanner: 0.5.4-0rc6 at d163; drop(clamd()) deliver(BogoFilter()) X-Sagator-id: 20060203-121520-0001-06515-FwTnQt Subject: [d-kernel] Fwd: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. X-BeenThere: devel-kernel@lists.altlinux.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2006 07:15:25 -0000 Archived-At: List-Archive: List-Post: --AqsLC8rIMeq19msA Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable ----- Forwarded message from Nigel Cunningham ----- Date: Fri, 3 Feb 2006 09:18:02 +1000 =46rom: Nigel Cunningham To: Andrew Morton , suspend2-devel@lists.suspend2 Cc: torvalds@osdl, linux-kernel@vger.kernel, Pavel Machek Subject: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. X-String-ID: 39 X-UWA-Client-IP: 130.95.13.29 (UWA) X-UWA-Client-IP: 203.143.238.98 (EXTERNAL) User-Agent: KMail/1.9.1 Hi Andrew et al. On Friday 03 February 2006 07:27, Andrew Morton wrote: > Pavel Machek wrote: > > > I don't want to argue Pavel. I want to give users the best suspend to > > > disk implementation they can get. If you want to argue, you can do so > > > with > > > > I want to create best suspen that can be still merged into kernel; I > > guess thats the difference. Anyway I believe that most of suspend > > should be done in userspace -- most of it can. But I guess you need to > > hear it from Linus/Andrew, so... > > You're unlikely to hear anything dispositive from either of us on this. > You three guys know far more than us about suspend, so it would be silly > for us to be making the technical decisions. When cornered, we're more > likely to come out with general kernel platitudes such as "doing it in > userspace:good" and "crashing the kernel:bad" and "incremental development > with early merges:good" and "mucking up the kernel source:bad". > > What we hope and expect is that you'll come up with an agreed path in > accordance with general kernel coding and development principles. Linus > and I don't want to have to make tiebreak decisions - if we have to do > that, the system has failed. > > Random thoughts: > > - swsusp has been a multi-year ongoing source of churn and bug reports. > It hasn't been a big success and we have a way to go yet. > > - People seem to be doing too much development on the swsusp core and not > enough development out where the actual problems are: drivers which don= 't > suspend and resume correctly. > > - suspend2 is at a disadvantage because swsusp was merged first. If > neither of the solutions had been merged and if we were evaluating them > side-by-side, suspend2 would have a much better chance. This is a > problem. > > - If you want my cheerfully uninformed opinion, we should toss both of > them out and implement suspend3, which is based on the kexec/kdump > infrastructure. There's so much duplication of intent here that it's n= ot > funny. And having them separate like this weakens both in the area whe= re > the real problems are: drivers. > > - Justifying the inclusion of a feature by the appearance and usefulness > of the end result doesn't really work in this world. There are numerous > unmerged kernel features out there which work well and look great. But > we will look under the hood, and that's when problems start. > > > So, as promised, there's nothing useful here. What we'd most like to see > is for Nigel to start working on in-kernel swsusp, merging up the good bi= ts > from suspend2 in some evolutionary incremental manner under which the > kernel continually improves. If, at the end of the day, that ends up with > us having a complete implementation of suspend2, well, Mission > Accomplished? Thanks for the reply. You're right. It doesn't help at all :) Well, actually it does. It reminds me why I started working on this in the first place. It wasn't= =20 because I wanted to be a big shot kernel developer or the like, or have my= =20 name in the kernel credits. It was because I wanted to use the code. So, given that I'm perfectly willing to send Pavel patches, but he's not=20 willing to take them, I guess I the best thing I can do is to just let Pave= l=20 have his way, give up on the concept of merging Suspend2 and maintain it ou= t=20 of tree. When Pavel and Rafael get swsusp up to scratch, I can stop doing= =20 that and just use their version. Well, that's what I think at the moment. Let's see how things progress. Nigel --=20 See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode _______________________________________________ Suspend2-devel mailing list Suspend2-devel@lists.suspend2.net http://lists.suspend2.net/mailman/listinfo/suspend2-devel ----- End forwarded message ----- --=20 WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(8): =E9 =D4=C1=CB =D7=CF =CD=CE=CF=C7=C9=C8 =D0=C1=CB=C5=D4=C1=C8 =D0=D2=CF=C3= =D7=C5=D4=C1=C0=D4 =D0=D2=C5=C4=D0=CF=DE=D4=C5=CE=C9=D1 maintainer'=CF=D7, = =C9 =D7=C2=C9=D7=C1=C0=D4 =CF=CE=C9 =CE=C1=D3=D4=D2=CF=CA=CB=C9 =D7 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC= =D1, =C9 =D4=D1=CE=D5=D4 =CF=CE=C9 =DA=C1 =D3=CF=C2=CF=CA =D0=C1=CB=C5=D4= =D9 =CB=C1=D3=D4=CF=CD=CE=D9=C8 =D2=C1=D3=D4=D2=CF=D7=D9=C8 =DB=D2=C9=C6=D4=CF=D7, =CB=C1=CB =D4=CF=D4 =D6= =C5 gnome-terminal (=C9=CE=D4=C5=D2=C5=D3=CE=CF, =DA=C1=DE=C5=CD =CD=D9 =C5= =C7=CF =D4=CF=C7=C4=C1 =D3=CF=C2=C9=D2=C1=CC=C9 =D3 vte?)... -- mhz in devel@ --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD4v5XB4Vf7hFmt5URAvT8AKCznoiMOlh9OHIdgUDGKM3PCupV9QCeIbQY kOG9zVed4upCaM9r30TedjE= =Zf7g -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA--