linux-kernel - Re: New MMC maintainer needed

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 3 Aug 2009 14:41:50 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Adrian Hunter <adrian.hunter@...ia.com>
Cc:	pierre@...man.eu, matt@...sole-pimps.org,
	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	nico@....org, nicolas.ferre@....atmel.com, hskinnemoen@...el.com,
	tony@...mide.com, david-b@...bell.net, 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
Subject: Re: New MMC maintainer needed

On Mon, 03 Aug 2009 14:13:28 +0300
Adrian Hunter <adrian.hunter@...ia.com> wrote:

> Pierre Ossman wrote:
> > On Fri, 31 Jul 2009 11:54:07 +0100
> > Matt Fleming <matt@...sole-pimps.org> wrote:
> > 
> >> On Fri, Jul 31, 2009 at 12:26:23PM +0200, Pierre Ossman wrote:
> >>> [PATCH 0/32] mmc and omap_hsmmc patches
> >>> http://marc.info/?t=124722953900010&r=1&w=2
> >>>
> >>> I haven't looked through these at all. The ones affecting the core
> >>> probably need some thorough reviews.
> >>>
> >>> I did notice the patch to say which cards a controller supports though,
> >>> and I'm very sceptical about that one. The scanning process should work
> >>> anyway, and the performance impact should be negligible as it is only
> >>> on init. So that patch only adds complexity and confusion IMO.
> >>>
> >> How much complexity does it really add? Surely it's better to give the
> >> host controller driver writers the ability to not entertain supporting
> >> some cards if they cannot be used? If they want to avoid the scanning
> >> process for certain cards, why not let them?
> >>
> > 
> > Let's look at the pros and cons of this:
> 
> But the cons are all subjective.
> 
> > Con:
> > 
> >  - The scanning code gets less clear as you increase the number of
> >    possible paths through it.
> > 
> >  - Different systems will have different init sequences, possibly
> >    provoking bugs in the cards.
> > 
> >  - Host driver writers now have more capability bits they have to
> >    consider. And these might be less than obvious since SD/MMC/SDIO are
> >    normally compatible so these bits seem useless.
> > 
> >  - With the current logic (which was better in the first version),
> >    "normal" drivers will have to explicitly state that they work as
> >    intended by setting all bits.

Subjective or not, they are real and valid.

> And the pro is objective.
> 
> > Pro:
> > 
> >  - A slightly reduced scanning time.
> 
> That's great!  Why do you disregard this so easily?

Coz nobody quantified it.  Let's go to the changelog:

: Some hosts can accept only certain types of cards.  For example, an eMMC
: is MMC only and a uSD slot may be SD only.  However the MMC card scanning
: logic checks for all card types one by one.
: 
: Add host capabilities to specify which card types can be used, and amend
: the card scanning logic to skip scanning for those types which cannot be
: used.

See, it provides no reason at all for adding this additional complexity.

Now we're told "it's faster".  OK.  How much faster?  Show us the
numbers so we can all understand why the change is justifiable!

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