New rule for xD FTL driver

New rule for xD FTL driver

[Maxim Levitsky]

Hi,

I have written a driver for xD card reader and xD/SmartMedia FTL that is
usually mandatory to use with xD cards.

I think this can be added to 80-drivers.rule
SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"

And this for devicekit, not sure where to add:
KERNEL="smblk*", ENV{ID_DRIVE_FLASH}="1"


Best regards,
Maxim Levitsky

Re: New rule for xD FTL driver

[Greg KH]

On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> Hi,
> 
> I have written a driver for xD card reader and xD/SmartMedia FTL that is
> usually mandatory to use with xD cards.
> 
> I think this can be added to 80-drivers.rule
> SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"

Why does this module not have the proper MODULE_DEVICE() or aliases in
it so that you don't have to manually load the module?  This should not
need to be a udev rule.

thanks,

greg k-h

Re: New rule for xD FTL driver

[Maxim Levitsky]

On Mon, 2010-06-14 at 09:46 -0700, Greg KH wrote: 
> On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> > Hi,
> > 
> > I have written a driver for xD card reader and xD/SmartMedia FTL that is
> > usually mandatory to use with xD cards.
> > 
> > I think this can be added to 80-drivers.rule
> > SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
> 
> Why does this module not have the proper MODULE_DEVICE() or aliases in
> it so that you don't have to manually load the module?  This should not
> need to be a udev rule.

Well mtd system is not using bus model.
However a card needs to be probed (theoteticly) by several high-level
FTL drivers to make one of them to bind to it. (In fact several can bind
at same now, which is both bad and good feature).

I understand that module can have aliases so it can bind to a bus.

Of course I can do a 'request_module', but I think it isn't nice thing
to do.

I can also attach alias to uevent which is sent to udev, but its also
not easy to do with mtd.


Best regards,
Maxim Levitsky

Re: New rule for xD FTL driver

[Greg KH]

On Tue, Jun 15, 2010 at 02:55:49AM +0300, Maxim Levitsky wrote:
> On Mon, 2010-06-14 at 09:46 -0700, Greg KH wrote: 
> > On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> > > Hi,
> > > 
> > > I have written a driver for xD card reader and xD/SmartMedia FTL that is
> > > usually mandatory to use with xD cards.
> > > 
> > > I think this can be added to 80-drivers.rule
> > > SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
> > 
> > Why does this module not have the proper MODULE_DEVICE() or aliases in
> > it so that you don't have to manually load the module?  This should not
> > need to be a udev rule.
> 
> Well mtd system is not using bus model.

Why not?  It should be fixed to do so.

> However a card needs to be probed (theoteticly) by several high-level
> FTL drivers to make one of them to bind to it. (In fact several can bind
> at same now, which is both bad and good feature).

Then why would you write a rule to automatically load the module on the
system no matter what?

> I understand that module can have aliases so it can bind to a bus.

module aliases are used by modprobe to know what module to load when a
device is found on a bus.

> Of course I can do a 'request_module', but I think it isn't nice thing
> to do.

Agreed.  But as it looks like you always want this module loaded, why
not just make it part of your mtd core?

thanks,

greg k-h

Re: New rule for xD FTL driver

[Maxim Levitsky]

On Mon, 2010-06-14 at 20:19 -0700, Greg KH wrote:
> On Tue, Jun 15, 2010 at 02:55:49AM +0300, Maxim Levitsky wrote:
> > On Mon, 2010-06-14 at 09:46 -0700, Greg KH wrote: 
> > > On Sat, Jun 12, 2010 at 03:54:04PM +0300, Maxim Levitsky wrote:
> > > > Hi,
> > > > 
> > > > I have written a driver for xD card reader and xD/SmartMedia FTL that is
> > > > usually mandatory to use with xD cards.
> > > > 
> > > > I think this can be added to 80-drivers.rule
> > > > SUBSYSTEM="mtd", RUN+="/sbin/modprobe sm_ftl"
> > > 
> > > Why does this module not have the proper MODULE_DEVICE() or aliases in
> > > it so that you don't have to manually load the module?  This should not
> > > need to be a udev rule.
> > 
> > Well mtd system is not using bus model.
> 
> Why not?  It should be fixed to do so.

Of course.
But I currently try to avoid changes that will result in changes in
areas I can't test.
This is one magnitude harder work, and I don't yet feel confident doing
so.




> 
> > However a card needs to be probed (theoteticly) by several high-level
> > FTL drivers to make one of them to bind to it. (In fact several can bind
> > at same now, which is both bad and good feature).
> 
> Then why would you write a rule to automatically load the module on the
> system no matter what?
> 
> > I understand that module can have aliases so it can bind to a bus.
> 
> module aliases are used by modprobe to know what module to load when a
> device is found on a bus.
> 
> > Of course I can do a 'request_module', but I think it isn't nice thing
> > to do.
> 
> Agreed.  But as it looks like you always want this module loaded, why
> not just make it part of your mtd core?
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?


Best regards,
	Maxim Levitsky

Re: New rule for xD FTL driver

[David Woodhouse]

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?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Re: New rule for xD FTL driver

[Maxim Levitsky]

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.
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.

I will create a prober for all FTLs currently supported by mtd core.

BTW, speaking of the bus model, it won't help at all, because there is
no real bus involved. Probing of the MTD is required anyway.

Best regards,
Maxim Levitsky

Re: New rule for xD FTL driver

[Greg KH]

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

Re: New rule for xD FTL driver

[Maxim Levitsky]

On Tue, 2010-06-15 at 07:55 -0700, Greg KH wrote: 
> 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?
A temporarily solution which is also more or less ok.
I am not writing a rule to load all FTL driver, but only the sm_ftl.
Maybe I write the prober now after all though.

Best regards,
Maxim Levitsky

Re: New rule for xD FTL driver

[Maxim Levitsky]

On Tue, 2010-06-15 at 18:27 +0300, Maxim Levitsky wrote: 
> On Tue, 2010-06-15 at 07:55 -0700, Greg KH wrote: 
> > 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?
> A temporarily solution which is also more or less ok.
> I am not writing a rule to load all FTL driver, but only the sm_ftl.
> Maybe I write the prober now after all though.

Can udev helper tell udev to load modules by setting some variable?

Because otherwise I would need to export a variable for each FTL, and
have a rule for each such variable to load a module.

Best regards,
Maxim Levitsky

Re: New rule for xD FTL driver

[Greg KH]

On Tue, Jun 15, 2010 at 06:27:35PM +0300, Maxim Levitsky wrote:
> On Tue, 2010-06-15 at 07:55 -0700, Greg KH wrote: 
> > 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?
> A temporarily solution which is also more or less ok.

If it is "ok", and a "temporary" solution, then just move your kernel
module into the core mtd.ko module and you should be fine.

But odds are, you will not convince the mtd maintainer that's an ok
solution either :)

thanks,

greg k-h

Re: New rule for xD FTL driver

[Greg KH]

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.

good luck,

greg k-h

Re: New rule for xD FTL driver

[David Woodhouse]

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.

Except we don't do that for file systems. We require an explicit mount
call, and all fstype probing is done in userspace.

-- 
dwmw2

Re: New rule for xD FTL driver

[Greg KH]

On Tue, Jun 15, 2010 at 06:01:31PM +0100, David Woodhouse 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.
> 
> Except we don't do that for file systems. We require an explicit mount
> call, and all fstype probing is done in userspace.

True.

So, what do you suggest for how to know how to load the individual mtd
drivers?

thanks,

greg k-h

Re: New rule for xD FTL driver

[Maxim Levitsky]

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.
> 
> good luck,
> 
> greg k-h


It seems to work just fine.
mtdchar I see it loaded automatically anyway due to char device alias.

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"
echo "ID_DRIVE_FLASH=1"

Best regards,
Maxim Levitsky

Re: New rule for xD FTL driver

[Kay Sievers]

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.

What will the module do when it's loaded? Scan all mtd devices and
check if there is something it should bind to?

Kay

Re: New rule for xD FTL driver

[Maxim Levitsky]

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

Re: New rule for xD FTL driver

[Maxim Levitsky]

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