On Tue, 2010-06-15 at 21:02 +0200, Kay Sievers wrote:
> On Tue, Jun 15, 2010 at 19:46, Maxim Levitsky <maximlevitsky@xxxxxxxxx> 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
--
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
