Handling /etc/modprobe.d and module load order

[Amit]

Hello,

I am using debhelper 9.20120115 and would like some advice on bundling
/etc/modprobe.d/package.modprobe and /etc/modules.

1. I am currently using dh_installmodules to install package.modprobe.
However, I noticed that the automated debhelper commands in
postins/postrm don't run update-initramfs. Is updating initramfs not
necessary?

2. I also need to specify module load order so I am bundling
/etc/modules. However, there doesn't seem to be a debhelper script
to handle /etc/modules.

I searched the list archives and found conflicting arguments regarding
the use of update-initramfs after updating /etc/modules or
/etc/modprobe.d/.

Thanks for any help,
Amit

[Ben Hutchings]

Post by Amit
Hello,
I am using debhelper 9.20120115 and would like some advice on bundling
/etc/modprobe.d/package.modprobe and /etc/modules.
1. I am currently using dh_installmodules to install package.modprobe.
However, I noticed that the automated debhelper commands in
postins/postrm don't run update-initramfs. Is updating initramfs not
necessary?

That depends on what are you trying to do.

Post by Amit
2. I also need to specify module load order so I am bundling
/etc/modules. However, there doesn't seem to be a debhelper script
to handle /etc/modules.

Don't ever touch /etc/modules, that's for the user/administrator. You
can load modules from an init script if there is really no better way.

Post by Amit
I searched the list archives and found conflicting arguments regarding
the use of update-initramfs after updating /etc/modules or
/etc/modprobe.d/.

/etc/modules is used by the init scripts, not the initramfs.
/etc/modprobe.d *does* get copied to the initramfs and I think you're
right that update-initramfs should generally be called after it's
updated. Perhaps initramfs-tools should have a file trigger for it,
though.

Ben.

[Michael Biebl]

Post by Ben Hutchings

Post by Amit
2. I also need to specify module load order so I am bundling
/etc/modules. However, there doesn't seem to be a debhelper script
to handle /etc/modules.

Don't ever touch /etc/modules, that's for the user/administrator. You
can load modules from an init script if there is really no better way.

You can use a modules-load.d file [1]. While the idea originally comes
from systemd, it has also been implemented in the kmod (f.n.a.
module-init-tools) package.

Cheers,
Michael

[1] http://0pointer.de/public/systemd-man/modules-load.d.html

[Amit]

[snip]

Post by Michael Biebl

Post by Ben Hutchings
Don't ever touch /etc/modules, that's for the user/administrator. You
can load modules from an init script if there is really no better way.

You can use a modules-load.d file [1]. While the idea originally comes
from systemd, it has also been implemented in the kmod (f.n.a.
module-init-tools) package.

Thanks. Looks like this is only implemented in the newer debian systems
correct?

Couldn't find it in squeeze.

Post by Michael Biebl
Cheers,
Michael
[1] http://0pointer.de/public/systemd-man/modules-load.d.html

[Amit]

Ben Hutchings <ben <at> decadent.org.uk> writes:

[snip]

Post by Ben Hutchings

Post by Amit
1. I am currently using dh_installmodules to install package.modprobe.
However, I noticed that the automated debhelper commands in
postins/postrm don't run update-initramfs. Is updating initramfs not
necessary?

That depends on what are you trying to do.

Trying to load usbhid and passing a quirks parameter so that it ignores
a specific device. Then, I have my own kernel module to control that
device.

Post by Ben Hutchings

Post by Amit
2. I also need to specify module load order so I am bundling
/etc/modules. However, there doesn't seem to be a debhelper script
to handle /etc/modules.

Don't ever touch /etc/modules, that's for the user/administrator. You
can load modules from an init script if there is really no better way.

OK. So I blacklist the modules in package.modprobe. And then load them
in the order I want in package.init by just calling modprobe?

Post by Ben Hutchings

Post by Amit
I searched the list archives and found conflicting arguments regarding
the use of update-initramfs after updating /etc/modules or
/etc/modprobe.d/.

/etc/modules is used by the init scripts, not the initramfs.
/etc/modprobe.d *does* get copied to the initramfs and I think you're
right that update-initramfs should generally be called after it's
updated. Perhaps initramfs-tools should have a file trigger for it,
though.

I ran some tests, and we definitely do need to update initramfs after
any changes under /etc/modprobe.d.

Thanks for reply.

[Ben Hutchings]

Post by Amit
[snip]

Post by Ben Hutchings

Post by Amit
1. I am currently using dh_installmodules to install package.modprobe.
However, I noticed that the automated debhelper commands in
postins/postrm don't run update-initramfs. Is updating initramfs not
necessary?

That depends on what are you trying to do.

Trying to load usbhid and passing a quirks parameter so that it ignores
a specific device. Then, I have my own kernel module to control that
device.

What is this driver?

Post by Amit

Post by Ben Hutchings

Post by Amit
2. I also need to specify module load order so I am bundling
/etc/modules. However, there doesn't seem to be a debhelper script
to handle /etc/modules.

Don't ever touch /etc/modules, that's for the user/administrator. You
can load modules from an init script if there is really no better way.

OK. So I blacklist the modules in package.modprobe. And then load them
in the order I want in package.init by just calling modprobe?

Unless you're doing something very unusual, you let udev load the module
automatically based on its device ID table.

Post by Amit

Post by Ben Hutchings

Post by Amit
I searched the list archives and found conflicting arguments regarding
the use of update-initramfs after updating /etc/modules or
/etc/modprobe.d/.

/etc/modules is used by the init scripts, not the initramfs.
/etc/modprobe.d *does* get copied to the initramfs and I think you're
right that update-initramfs should generally be called after it's
updated. Perhaps initramfs-tools should have a file trigger for it,
though.

I ran some tests, and we definitely do need to update initramfs after
any changes under /etc/modprobe.d.

Yes, usbhid is included in the initramfs so any options need to be in
there too.

Ben.

[Amit]

Post by Ben Hutchings

Post by Amit
Trying to load usbhid and passing a quirks parameter so that it ignores
a specific device. Then, I have my own kernel module to control that
device.

What is this driver?

It is a driver for a PIC microcontroller board. I was using usbhid but
there was a bug that I couldn't work around. So I am bundling a custom
kernel module. I need to blacklist that device from usbhid otherwise it
tries to control the device.

Post by Ben Hutchings

Post by Amit
OK. So I blacklist the modules in package.modprobe. And then load them
in the order I want in package.init by just calling modprobe?

Unless you're doing something very unusual, you let udev load the module
automatically based on its device ID table.

I haven't thought of this. How does this work in the case when usbhid
already has the device in its device ID table.

Thanks for your help.

Amit

[Ben Hutchings]

Post by Amit

Post by Ben Hutchings

Post by Amit
Trying to load usbhid and passing a quirks parameter so that it ignores
a specific device. Then, I have my own kernel module to control that
device.

What is this driver?

It is a driver for a PIC microcontroller board. I was using usbhid but
there was a bug that I couldn't work around.

A bug in which?

Post by Amit
So I am bundling a custom
kernel module. I need to blacklist that device from usbhid otherwise it
tries to control the device.

Post by Ben Hutchings

Post by Amit
OK. So I blacklist the modules in package.modprobe. And then load them
in the order I want in package.init by just calling modprobe?

Unless you're doing something very unusual, you let udev load the module
automatically based on its device ID table.

I haven't thought of this. How does this work in the case when usbhid
already has the device in its device ID table.

They both get loaded.

Ben.

Post by Amit
Thanks for your help.
Amit

[Ian Jackson]

Post by Ben Hutchings

Post by Amit
It is a driver for a PIC microcontroller board. I was using usbhid but
there was a bug that I couldn't work around.

A bug in which?

I assume a bug in the board which Amit wanted to work around by using
a stunt version of the usbhid driver.

Post by Ben Hutchings

Post by Amit
I haven't thought of this. How does this work in the case when usbhid
already has the device in its device ID table.

They both get loaded.

And how should Amit arrange that the stunt driver, not normal usbhid,
gets control of the device ?

Ian.

[Amit]

Post by Ian Jackson

Post by Ben Hutchings

Post by Amit
It is a driver for a PIC microcontroller board. I was using usbhid but
there was a bug that I couldn't work around.

A bug in which?

I assume a bug in the board which Amit wanted to work around by using
a stunt version of the usbhid driver.

Yes, that is correct. The bug is in the firmware of the PIC
microcontroller.

Post by Ian Jackson

Post by Ben Hutchings

Post by Amit
I haven't thought of this. How does this work in the case when usbhid
already has the device in its device ID table.

They both get loaded.

And how should Amit arrange that the stunt driver, not normal usbhid,
gets control of the device ?

This is main problem. Both the drivers try and control the device. The
only work around I could come up with was to pass a usbhid quirks to
ignore this specific board and then load the custom driver.

Thanks for the reply.

[Marco d'Itri]

Post by Amit
This is main problem. Both the drivers try and control the device. The
only work around I could come up with was to pass a usbhid quirks to
ignore this specific board and then load the custom driver.

Actually there is a different solution:

# stop handling the device identified by VID and PID
ACTION=="add", SUBSYSTEM=="drivers", \
ENV{DEVPATH}=="/bus/usb-serial/drivers/usbhid", \
ATTR{remove_id}="xxxx yyyy"

# if no driver has claimed the interface yet, load your_driver
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_interface", \
ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", \
DRIVER=="", \
RUN+="/sbin/modprobe -b your_driver"

Or just:

echo 'xxxx yyyy' > /sys/bus/usb/drivers/usbhid/remove_id
modprobe your_driver

[Amit]

Marco d'Itri <md <at> Linux.IT> writes:

[snip]

Post by Marco d'Itri
echo 'xxxx yyyy' > /sys/bus/usb/drivers/usbhid/remove_id
modprobe your_driver

Tried this but it seems the PIC is buggier than I thought. There are
times when it disconnects and reconnects itself. As soon as the
reconnect happens, usbhid takes over the device. Thus, negating the
above command.

I ended up placing a line in */etc/default/grub* that passes the usbhid
quirks and have the postinst call update-grub. This passes the quirks to
kernel during boot so all seems well now.

Thanks,
Amit