On Fri, Jun 16, 2017 at 11:32 AM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> On 8 June 2017 at 10:53, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>> +#else /* !IS_ENABLED(CONFIG_MMC_BLOCK) */
>> +
>> +static int mmc_add_block_debugfs(struct mmc_card *card, struct dentry *root)
>> +{
>
> So does this really work as expected?
>
> Currently one can build the mmc block as a separate module. If that
> module is inserted after the mmc core module attempts to register the
> debugfs nodes, we would end up in this stub function, right?
Not really. IS_ENABLED() is a compile-time flag. The stub is not even
compiled in if the block layer is selected as module.
I.e. if CONFIG_MMC_BLOCK is "y" or "m" then the real function gets
compiled in. If it is "n" the stub gets compiled in.
> In other words, those system that for some odd reason decide to insmod
> the mmc block module at a later point, won't be given the debugfs
> nodes?
This is not really related, since I have all the debugfs files for the
block layer as static functions in this patch, i.e. if the block layer
is inserted, the debugfs files come up.
On a broader note, AFAIK it is already impossible to insert the block
module after the core module (if it was selected as "m" at compile time),
as the block module must be inserted first, or the core module cannot
resolve the symbols it needs from the block module.
insmod will fail, and modprobe will load the required modules first,
so it orders the block layer to load before the core so that the symbols
are resolved.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
