[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080628173637.53e3279f@hskinnemo-gx745.norway.atmel.com>
Date: Sat, 28 Jun 2008 17:36:37 +0200
From: Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To: Pierre Ossman <drzeus-mmc@...eus.cx>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] mmc: Add per-card debugfs support
Pierre Ossman <drzeus-mmc@...eus.cx> wrote:
> > Hmm...I thought card.c seemed like a good place for card-specific debug
That should be bus.c of course...
> > information. Even though this particular attribute isn't relevant to
> > some types of cards, is that a reason to create the whole directory
> > elsewhere and add complicated dependencies between files?
> >
>
> The directory might be suitable there, just not the "status" file. The
> MMC code used to be a horrible mess of "if":s, "but":s and "when":s in
> order to handle the crappy details of MMC vs SD. I'd like to avoid
> going back to that nightmare as much as possible. The layering can
> never be perfect, but right now it's at least just core.c that needs to
> know about the different systems.
>
> An alternative to sticking it into mmc.c is to create a debugfs.c that
> contains all the uglyness. Debugging code isn't quite as important to
> keep crystal clear.
But if we're going to rely on gcc optimizing the whole thing away when
debugfs is disabled, we must keep these buggers in the same file as its
caller...
Though I suppose an extra function call that does nothing at host and
card registration time isn't a very high price to pay for cleaner code.
Haavard
--
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