[PATCH v13 4/4]: mtdoops: refactor as a kmsg_dumper

[Artem Bityutskiy]

On Wed, 2009-11-11 at 12:27 +0100, Simon Kagstrom wrote:
> On Wed, 11 Nov 2009 12:29:42 +0200
> Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> 
> > On Wed, 2009-11-11 at 10:46 +0100, Simon Kagstrom wrote:
> > > On Tue, 10 Nov 2009 18:11:33 +0200
> > > 
> > > > Do we really need this notifiers? Would not it be better to open mtd
> > > > device straight in the module_init function instead?
> > > 
> > > If the mtdoops driver is built into the kernel, module_init might be
> > > (and I believe will be) called before the MTD partitions have been
> > > created. With the MTD notifiers, this problem is worked around.
> > 
> > But this is why we have late_initcall(), which we can use instead of
> > module_init().
> 
> OK, makes sense (you learn something new every day!). But I still have
> one, perhaps artificial, use-case for keeping it as-is: MTD devices
> might show up later if they are loaded as modules. In my case I use
> phram as a module, and if I were to use that with MTDoops in the
> kernel, I still need the notifiers.

I do not insist at all, but I thought this is just error prone way. You
load mtdoops, which then lurks, and when appropriate MTD device appears,
it grabs it. But what if I just forgot to unload mtdoops and it grabs my
mtd1 device and formats it?

Besides, currently mtdoops may fail to grab the mtd device for some
reasons (an error), and all you have is an error message. If you do not
notice it, you may happily think you have working mtdoops, while you do
not.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)