From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Tue, 15 Jun 2010 14:55:25 +0000 Subject: Re: New rule for xD FTL driver Message-Id: <20100615145525.GB16274@kroah.com> List-Id: References: <1276347244.4481.15.camel@maxim-laptop> In-Reply-To: <1276347244.4481.15.camel@maxim-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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