Re: New rule for xD FTL driver

[Maxim Levitsky <maximlevitsky@gmail.com>]

On Tue, 2010-06-15 at 22:29 +0300, Maxim Levitsky wrote: 
> On Tue, 2010-06-15 at 21:02 +0200, Kay Sievers wrote: 
> > On Tue, Jun 15, 2010 at 19:46, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> > > On Tue, 2010-06-15 at 09:05 -0700, Greg KH wrote:
> > >> On Tue, Jun 15, 2010 at 06:45:48PM +0300, Maxim Levitsky wrote:
> > >> > Can udev helper tell udev to load modules by setting some variable?
> > >>
> > >> Not really, except for the modalias stuff.  Use that if you can.
> > >>
> > >> But I think you've pointed out the real solution already.  You need to
> > >> look at the signature on the device and then know what to load, just
> > >> like we do for filesystems.
> > 
> > > It seems to work just fine.
> > > mtdchar I see it loaded automatically anyway due to char device alias.
> > 
> > What triggers char device aliases? You mean a static /dev with device
> > nodes without a current kernel device?
> > 
> > > So this rules does the trick:
> > >
> > > ACTION!="add", GOTO="mtd_probe_end"
> > > KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
> > > LABEL="mtd_probe_end"
> > >
> > > And all I have to do is to write the mtd_probe
> > >
> > > My current stub mtd-probe is:
> > >
> > > #!/bin/sh
> > > # $1 = device node
> > > echo "MODALIAS=sm_ftl"
> > 
> > Modaliases are not supposed to be defined by imported variables. They
> > are specified by the kernel, and should also be visible in sysfs, if
> > they are used.
> > 
> > Also modaliases have prefixes like: <subsystem>:<some id>, and should
> > never be plain module names, to allow module-init-tools to overwrite
> > things in a sane way. You might want to add MODULE_ALIAS("mtd:sm_ftl")
> > to the module itself, or whatever fits.
> But what will I do with this?
> 
> 
> 
> Let me explain again:
> I have low level driver that exposes mtd interface.
> And I have high level driver (sm_ftl) that using already existing code
> scans for new mtd devices, and binds to these that have 'magic'
> signature in first non-bad block.
> 
> The low level driver is loaded by PCI core.
> The high level driver isn't loaded by anyone.
> 
> 
> So I had following options:
> 
> 1. always load the sm_ftl as soon as mtd device appears. This wasn't
> accepted, and I more or less agree on that.
> 
> 2. As soon as mtd device appeared, spawn userspace helper that will look
> for 'magic' signature on its own, and then load the sm_ftl (or other
> FTLs).
> 
> 
> I partially implemented (2) by binding an udev rule to mtdchar device
> creating, which will be opened by my mtd_probe, and scanned for
> signature. If signature matches, I will export 'MODALIAS=<ftl driver>'
> 
> If you want I can add MODULE_ALIAS("mtd:sm_ftl") to sm_ftl.ko, but I
> still need the userspace helper to export
> 
> MODALIAS=mtd:sm_ftl
> 
> How else can userspace helper tell udev to load a module?
> (Sure I can spawn modprobe from it, or do something like that?
> 
> ACTION!="add", GOTO="mtd_probe_end"
> 
> KERNEL="mtd*ro", IMPORT{program}="mtd_probe --export $tempnode"
> KERNEL="mtd*ro", ENV{MTD_MODULE}="?*", RUN+="modprobe $MTD_MODULE"
> 
> LABEL="mtd_probe_end"
> 
> 
> mtd_probe.sh (placeholder, will be replaced with 'C' program)
> 
> #!/bin/sh
> # $1 = device node
> 
> # now we open and read the mtd mode
> 
> if [ $FOUND_SM_FTL_MAGIC = 1 ] ; then
> 	echo "MTD_MODULE=sm_ftl"
> fi
> 
> 
> 
> But why?
> 
> 
> Best regards,
> Maxim Levitsky
> 
Any update?

Best regards,
Maxim Levitsky