ALT Linux kernel packages development
 help / color / mirror / Atom feed
From: Andrey Rahmatullin <wrar-alt@mail.ru>
To: ALT Linux kernel packages development <devel-kernel@lists.altlinux.org>
Subject: [d-kernel] Fwd: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.
Date: Fri, 3 Feb 2006 11:55:19 +0500
Message-ID: <20060203065519.GA24501@wrars-comp.wrarsdomain> (raw)

[-- Attachment #1: Type: text/plain, Size: 4801 bytes --]

----- Forwarded message from Nigel Cunningham <nigel@suspend2> -----

Date: Fri, 3 Feb 2006 09:18:02 +1000
From: Nigel Cunningham <nigel@suspend2>
To: Andrew Morton <akpm@osdl>, suspend2-devel@lists.suspend2
Cc: torvalds@osdl, linux-kernel@vger.kernel,
	Pavel Machek <pavel@ucw>
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 <pavel@ucw> 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 not
>   funny.  And having them separate like this weakens both in the area where
>   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 bits
> 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 
because I wanted to be a big shot kernel developer or the like, or have my 
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 
willing to take them, I guess I the best thing I can do is to just let Pavel 
have his way, give up on the concept of merging Suspend2 and maintain it out 
of tree. When Pavel and Rafael get swsusp up to scratch, I can stop doing 
that and just use their version.

Well, that's what I think at the moment. Let's see how things progress.

Nigel
-- 
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 -----

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

И так во многих пакетах процветают предпочтения maintainer'ов, и вбивают
они настройки в пользователя, и тянут они за собой пакеты кастомных
растровых шрифтов, как тот же gnome-terminal (интересно, зачем мы его
тогда собирали с vte?)...
		-- mhz in devel@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

                 reply	other threads:[~2006-02-03  6:55 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060203065519.GA24501@wrars-comp.wrarsdomain \
    --to=wrar-alt@mail.ru \
    --cc=devel-kernel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux kernel packages development

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \
		devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com
	public-inbox-index devel-kernel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git