[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200908031851.24375.david-b@pacbell.net>
Date: Mon, 3 Aug 2009 18:51:23 -0700
From: David Brownell <david-b@...bell.net>
To: Pierre Ossman <pierre@...man.eu>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
nico@....org, nicolas.ferre@....atmel.com, hskinnemoen@...el.com,
tony@...mide.com, manuel.lauss@...il.com, mirq-linux@...e.qmqm.pl,
ppisa@...ron.com, jarkko.lavinen@...ia.com, ben@...ff.org,
saschasommer@...enet.de, avorontsov@...mvista.com, oakad@...oo.com,
ian@...menth.co.uk, HaraldWelte@...tech.com, JosephChan@....com.tw,
adrian.hunter@...ia.com
Subject: Re: New MMC maintainer needed
On Friday 31 July 2009, Pierre Ossman wrote:
> Restoring back the system state from MMC after a successful hibernation
> http://marc.info/?t=124818534700003&r=1&w=2
>
> I don't agree with this approach. The point of the workqueue is so that
> the kernel can do things in parallel, so this patch is a step back. The
> problem is really with how the kernel doesn't properly cope with
> asynchronous disk scanning during bootup. The root_delay parameter was
> added for this for the "normal" case, but it seems more work is needed.
Doesn't handing of resumes needs more attention overall?
Example, root on eMMC (e.g. a 32-MByte non-removable chip) wouldn't
resume at all well the last time I checked ... mounted file systems
(not just root) made trouble. Hardware that reliably reports card
insert/remove was rude in the same ways.
- Dave
--
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/
Powered by blists - more mailing lists