absolute firmware paths

absolute firmware paths

[Sebastian Kuzminsky]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

Hi folks, I'm looking into using request_firmware()/udev to get firmware
into a couple of device drivers i'm writing, but I want to be able
to provide absolute paths for the firmware file and have firmware.sh
honor it.

The drivers are for a family of FPGA-based cards, mostly PCI.  We're
using the cards for motion control of machine tools and other robots,
see <http://www.linuxcnc.org>.

Anyway, the drivers and the firmware are distributed together.  A common
use case for many of our developers and some of our users is to check
out the source code, maybe hack on it some, build it, and run it out of
the sandbox (without installing).  The problem is that udev can't find
the firmwares in peoples home directories.

My proposal is to have the driver accept a modparam giving the absolute
path to the firmware file the user wants, and have the firmware.sh
helper read it from there, bypassing the normal firmware search path.

In the other use case, when the software is installed properly, the
modparam can be skipped and the driver will request default firmware
using relative paths (and udev will find the firmware in /lib/firmware).

I've attached a patch against udev.git showing what I mean.

Comments?


-- 
Sebastian Kuzminsky
"The brain is [a machine]. The fact that it's made out of meat is a
red herring."  -- David Adler <http://www.spectrum.ieee.org/print/6268>


[-- Attachment #2: udev-absolute-firmware-paths.patch --]
[-- Type: text/x-diff, Size: 791 bytes --]

diff --git a/extras/firmware/firmware.sh b/extras/firmware/firmware.sh
index b89b428..3d9cc61 100755
--- a/extras/firmware/firmware.sh
+++ b/extras/firmware/firmware.sh
@@ -9,0 +10,9 @@ err() {
+try_firmware() {
+	FILE=$1
+	[ -e "$FILE" ] || return 0
+	echo 1 > /sys$DEVPATH/loading
+	cat "$FILE" > /sys$DEVPATH/data
+	echo 0 > /sys$DEVPATH/loading
+	exit 0
+}
+
@@ -15,7 +24,9 @@ fi
-for DIR in $FIRMWARE_DIRS; do
-	[ -e "$DIR/$FIRMWARE" ] || continue
-	echo 1 > /sys$DEVPATH/loading
-	cat "$DIR/$FIRMWARE" > /sys$DEVPATH/data
-	echo 0 > /sys$DEVPATH/loading
-	exit 0
-done
+if [ $(echo $FIRMWARE | cut -b 1) = "/" ]; then
+	# absolute path
+	try_firmware $FIRMWARE
+else
+	# relative path, search the FIRMWARE_DIRS
+	for DIR in $FIRMWARE_DIRS; do
+		try_firmware $DIR/$FIRMWARE
+	done
+fi

Re: absolute firmware paths

[Marcel Holtmann]

Hi Sebastian,

> I'm looking into using request_firmware()/udev to get firmware
> into a couple of device drivers i'm writing, but I want to be able
> to provide absolute paths for the firmware file and have firmware.sh
> honor it.
> 
> The drivers are for a family of FPGA-based cards, mostly PCI.  We're
> using the cards for motion control of machine tools and other robots,
> see <http://www.linuxcnc.org>.
> 
> Anyway, the drivers and the firmware are distributed together.  A common
> use case for many of our developers and some of our users is to check
> out the source code, maybe hack on it some, build it, and run it out of
> the sandbox (without installing).  The problem is that udev can't find
> the firmwares in peoples home directories.
> 
> My proposal is to have the driver accept a modparam giving the absolute
> path to the firmware file the user wants, and have the firmware.sh
> helper read it from there, bypassing the normal firmware search path.
> 
> In the other use case, when the software is installed properly, the
> modparam can be skipped and the driver will request default firmware
> using relative paths (and udev will find the firmware in /lib/firmware).

use symlinks like everybody else.

Regards

Marcel

Re: absolute firmware paths

[Sebastian Kuzminsky]

On Mon June 30 2008 23:20:50 Marcel Holtmann wrote:
> > Anyway, the drivers and the firmware are distributed together.  A common
> > use case for many of our developers and some of our users is to check
> > out the source code, maybe hack on it some, build it, and run it out of
> > the sandbox (without installing).  The problem is that udev can't find
> > the firmwares in peoples home directories.
> >
> > My proposal is to have the driver accept a modparam giving the absolute
> > path to the firmware file the user wants, and have the firmware.sh
> > helper read it from there, bypassing the normal firmware search path.
>
> use symlinks like everybody else.

That's an option, true.  However, it gets really inconvenient when you
have, for example, a stable version installed from the official package
and an experimental version in a sandbox in your home.

Developing kernel drivers is super convenient in Linux because you can
give insmod absolute paths to load a specific file out of your development
directory, or you can let modprobe auto-fetch the installed driver module
from the standard path.

It'd be great if the kernel's budding firmware support had a similar
flexibility, for firmware developers and others.  Allowing absolute
paths in request_firmware()/firmware.sh seems like a nice clean way to
provide this.

Is there a technical reason this is a bad idea, or is it a subjective
"bad smell" type of thing?  Because I dont smell it.


Alternatively, I suppose I could request a relative path beginning with
"../..", then followed by the absolute path I want.  Now *that* smells ;-)


-- 
Sebastian Kuzminsky
                you are the only light there is for yourself my friend
                                                     -- Gogol Bordello

Re: absolute firmware paths

[Marcel Holtmann]

Hi Sebastian,

> > > Anyway, the drivers and the firmware are distributed together.  A common
> > > use case for many of our developers and some of our users is to check
> > > out the source code, maybe hack on it some, build it, and run it out of
> > > the sandbox (without installing).  The problem is that udev can't find
> > > the firmwares in peoples home directories.
> > >
> > > My proposal is to have the driver accept a modparam giving the absolute
> > > path to the firmware file the user wants, and have the firmware.sh
> > > helper read it from there, bypassing the normal firmware search path.
> >
> > use symlinks like everybody else.
> 
> That's an option, true.  However, it gets really inconvenient when you
> have, for example, a stable version installed from the official package
> and an experimental version in a sandbox in your home.
> 
> Developing kernel drivers is super convenient in Linux because you can
> give insmod absolute paths to load a specific file out of your development
> directory, or you can let modprobe auto-fetch the installed driver module
> from the standard path.
> 
> It'd be great if the kernel's budding firmware support had a similar
> flexibility, for firmware developers and others.  Allowing absolute
> paths in request_firmware()/firmware.sh seems like a nice clean way to
> provide this.
> 
> Is there a technical reason this is a bad idea, or is it a subjective
> "bad smell" type of thing?  Because I dont smell it.

the kernel doesn't make any policy decision on where the firmware files
are stored. So this information doesn't belong there. A driver
requesting and absolute path is a driver with a bug.

Also since you are talking about development here. So what has this to
do with the upstream kernel and why do we need it there. You can always
install your own firmware.sh file that does special things in case files
are requested for your driver. And actually you don't even have to
overwrite firmware.sh for it. Simply install a new udev rule for only
that driver.

Regards

Marcel

Re: absolute firmware paths

[Sebastian Kuzminsky]

On Thu July 3 2008 22:50:57 Marcel Holtmann wrote:
> > It'd be great if the kernel's budding firmware support had a similar
> > flexibility, for firmware developers and others.  Allowing absolute
> > paths in request_firmware()/firmware.sh seems like a nice clean way to
> > provide this.
> >
> > Is there a technical reason this is a bad idea, or is it a subjective
> > "bad smell" type of thing?  Because I dont smell it.
>
> the kernel doesn't make any policy decision on where the firmware files
> are stored. So this information doesn't belong there. A driver
> requesting and absolute path is a driver with a bug.

I agree that's a bug in the normal, everything-is-installed case.  

I'm looking for a solution for a different use case, which is not well
supported out of the box.  My use case is a firmware developer who wants
to test out different firmwares they're hacking on in their sandboxes.

The cleanest solution I can think of for this is to add a modparam
string firmware_name to the driver, and let the developer pass in the
absolute path of the firmware they want the driver to request this time.
All this would need is a tiny change in the userspace helper script.

In the "everything-is-installed" case the firmware_name modparam is not
specified; the driver requests its default firmware (by relative path),
and firmware.sh fetches it out of the normal system firmware directories
just like now.


Do all the other firmware developers out there symlink their sandboxes
into /lib/firmware?  And update the symlink when they switch to a
different sandbox?  And remove it when they finally install the firmware?

To me that seems messier than the proposed alternative.


How is this suggestion worse than insmod allowing you to load drivers
from your home?  It seems like the same kind of thing, just for firmware.


> Also since you are talking about development here. So what has this to
> do with the upstream kernel and why do we need it there. You can always
> install your own firmware.sh file that does special things in case files
> are requested for your driver. And actually you don't even have to
> overwrite firmware.sh for it. Simply install a new udev rule for only
> that driver.

Yeah, our own udev rule and our own firmware.sh is one of the options
we're considering.  It'd be easy to do.  I just think it's a generally
good idea and I thought that upstream udev might be interested.


-- 
Sebastian Kuzminsky
                you are the only light there is for yourself my friend
                                                     -- Gogol Bordello

Re: absolute firmware paths

[Marcel Holtmann]

Hi Sebastian,

> > Also since you are talking about development here. So what has this to
> > do with the upstream kernel and why do we need it there. You can always
> > install your own firmware.sh file that does special things in case files
> > are requested for your driver. And actually you don't even have to
> > overwrite firmware.sh for it. Simply install a new udev rule for only
> > that driver.
> 
> Yeah, our own udev rule and our own firmware.sh is one of the options
> we're considering.  It'd be easy to do.  I just think it's a generally
> good idea and I thought that upstream udev might be interested.

using your own firmware.sh and an udev rule is so simply. So don't
bother the kernel with any changes. Also the kernel does not make policy
decisions. The /lib/firmware location is a userspace policy.

Regards

Marcel

Re: absolute firmware paths

[Sebastian Kuzminsky]

On Fri July 4 2008 02:30:25 Marcel Holtmann wrote:
> Hi Sebastian,
>
> > > Also since you are talking about development here. So what has this to
> > > do with the upstream kernel and why do we need it there. You can always
> > > install your own firmware.sh file that does special things in case
> > > files are requested for your driver. And actually you don't even have
> > > to overwrite firmware.sh for it. Simply install a new udev rule for
> > > only that driver.
> >
> > Yeah, our own udev rule and our own firmware.sh is one of the options
> > we're considering.  It'd be easy to do.  I just think it's a generally
> > good idea and I thought that upstream udev might be interested.
>
> using your own firmware.sh and an udev rule is so simply. So don't
> bother the kernel with any changes. Also the kernel does not make policy
> decisions. The /lib/firmware location is a userspace policy.

Did you read my email?

You're the only one here talking about putting policy in the kernel,
or making any kernel changes at all.

I'm suggesting a small change to the existing policy in *udev*.  This is
the list for discussing udev, no?


-- 
Sebastian Kuzminsky
                you are the only light there is for yourself my friend
                                                     -- Gogol Bordello

Re: absolute firmware paths

[Marcel Holtmann]

Hi Sebastian,

> > > > Also since you are talking about development here. So what has this to
> > > > do with the upstream kernel and why do we need it there. You can always
> > > > install your own firmware.sh file that does special things in case
> > > > files are requested for your driver. And actually you don't even have
> > > > to overwrite firmware.sh for it. Simply install a new udev rule for
> > > > only that driver.
> > >
> > > Yeah, our own udev rule and our own firmware.sh is one of the options
> > > we're considering.  It'd be easy to do.  I just think it's a generally
> > > good idea and I thought that upstream udev might be interested.
> >
> > using your own firmware.sh and an udev rule is so simply. So don't
> > bother the kernel with any changes. Also the kernel does not make policy
> > decisions. The /lib/firmware location is a userspace policy.
> 
> Did you read my email?
> 
> You're the only one here talking about putting policy in the kernel,
> or making any kernel changes at all.
> 
> I'm suggesting a small change to the existing policy in *udev*.  This is
> the list for discussing udev, no?

you are talking about adding a module parameter for a absolute path to
the driver. That is putting policy into the kernel.

And again, what is the big issue with an udev rule for your development
case?

Regards

Marcel

Re: absolute firmware paths

[Sebastian Kuzminsky]

This is my final email in this thread.  I'm done.


Marcel Holtmann wrote:
> you are talking about adding a module parameter for a absolute path to
> the driver. That is putting policy into the kernel.

The modparam is already there, so the user can select from among several 
installed firmwares.  The "policy decision" is firmly in userspace.


> And again, what is the big issue with an udev rule for your development
> case?

Again?  I just addressed this point in my email yesterday:

Sebastian Kuzminsky wrote:
 > Yeah, our own udev rule and our own firmware.sh is one of the options
 > we're considering.  It'd be easy to do.  I just think it's a generally
 > good idea and I thought that upstream udev might be interested.


But, you know, whatever.  Bye now, have a good one.


-- 
Sebastian Kuzminsky
                 you are the only light there is for yourself my friend
                                                      -- Gogol Bordello