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@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
>
Any update?
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
