Re: New rule for xD FTL driver

[Maxim Levitsky <maximlevitsky@gmail.com>]

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