On Tue, Jun 15, 2010 at 04:22:24PM +0300, Maxim Levitsky wrote: > On Tue, 2010-06-15 at 11:28 +0100, David Woodhouse wrote: > > On Tue, 2010-06-15 at 13:07 +0300, Maxim Levitsky wrote: > > > Maybe not statically linked in it, but I am not against making mtd core > > > load all compiled FTL drivers as soon as an mtd device is registred. > > > > > > David Woodhouse, what do you think about that? > > > > I'm not massively keen on that. An FTL is like a file system. Would you > > insist on loading all compiled file systems when an mtd device is > > registered? > > > > Would you submit udev patches which auto-load btrfs when a block device > > is registered, such as the patch I see in the mail to which I'm > > replying? > > This is very good point. > The correct solution therefore is to create a new probe tool to look at > new mtd device to see the 'filesystem magic', and them load the > corresponding FTL. Yes, that sounds like the correct thing to do. > However, this still requires mtdchar or mtdblock be present. > I think its not a bad idea to make mtdchar to load automatically on mtd > device addition, and then bind the prober to creation of /dev/mtd0... > (Which sure will be an udev rule) > > This is a bit out of my reach now because I am quite busy with exams, so > for now, it would be nice to have this udev rule (so users won't tell me > that my driver doesn't work), and later I sure fix that. No, as you pointed out, this is not the correct thing, so why would we want to add it this way? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
