UIO device name

UIO device name

[Joakim Tjernlund]

As far as I can see there isn't a way to name the /dev/uio%d device file
to something more useful, is that so?
I would like to name the device file from within the kernel so I can
find the correct device from userspace.
The very least is to control the minor(%d) number.

 Jocke

Re: UIO device name

[Paul Mundt]

On Wed, Sep 24, 2008 at 11:21:33AM +0200, Joakim Tjernlund wrote:
> As far as I can see there isn't a way to name the /dev/uio%d device file
> to something more useful, is that so?
> I would like to name the device file from within the kernel so I can
> find the correct device from userspace.
> The very least is to control the minor(%d) number.
> 
You have a couple of options for this:

	- the 'name' sysfs entry for each of the uio devices, which
	  corresponds to the uio device name.
	- extracting the relevant data from things like 'lsuio'.
	- hooking in the pretty mame through udev to create an alias.

All of the information you need is available for userspace to play with,
and you want to be relying on the device name itself, not the minor
number (where you have no gaurantee of the ordering).

Documentation/DocBook/uio-howto.tmpl also has some more information on
what sort of information is exposed.

Re: UIO device name

[Joakim Tjernlund]

On Wed, 2008-09-24 at 18:35 +0900, Paul Mundt wrote:
> On Wed, Sep 24, 2008 at 11:21:33AM +0200, Joakim Tjernlund wrote:
> > As far as I can see there isn't a way to name the /dev/uio%d device file
> > to something more useful, is that so?
> > I would like to name the device file from within the kernel so I can
> > find the correct device from userspace.
> > The very least is to control the minor(%d) number.
> > 
> You have a couple of options for this:
> 
> 	- the 'name' sysfs entry for each of the uio devices, which
> 	  corresponds to the uio device name.
> 	- extracting the relevant data from things like 'lsuio'.
> 	- hooking in the pretty mame through udev to create an alias.

Right, but I want to do it from within the kernel when I create the
device because that the only place I truly know what HW the uio maps to.

I found that this works:
 struct uio_info *info,
 struct uio_device *idev;

 idev = info->uio_dev;
 device_rename(idev->dev, "irq4");

but then I have to copy the private uio_device struct from uio.c
Is there a better way to get at idev->dev?

 Jocke

Re: UIO device name

[Paul Mundt]

On Wed, Sep 24, 2008 at 11:57:59AM +0200, Joakim Tjernlund wrote:
> On Wed, 2008-09-24 at 18:35 +0900, Paul Mundt wrote:
> > On Wed, Sep 24, 2008 at 11:21:33AM +0200, Joakim Tjernlund wrote:
> > > As far as I can see there isn't a way to name the /dev/uio%d device file
> > > to something more useful, is that so?
> > > I would like to name the device file from within the kernel so I can
> > > find the correct device from userspace.
> > > The very least is to control the minor(%d) number.
> > > 
> > You have a couple of options for this:
> > 
> > 	- the 'name' sysfs entry for each of the uio devices, which
> > 	  corresponds to the uio device name.
> > 	- extracting the relevant data from things like 'lsuio'.
> > 	- hooking in the pretty mame through udev to create an alias.
> 
> Right, but I want to do it from within the kernel when I create the
> device because that the only place I truly know what HW the uio maps to.
> 
> I found that this works:
>  struct uio_info *info,
>  struct uio_device *idev;
> 
>  idev = info->uio_dev;
>  device_rename(idev->dev, "irq4");
> 
> but then I have to copy the private uio_device struct from uio.c
> Is there a better way to get at idev->dev?
> 
I fail to see what this will buy you that you can't already do with udev
(or a set of scripts that look at sysfs) today. "the only place I truly
know what HW the uio maps to" doesn't make any sense, the name is fully
preserved and exposed. If you can't figure out your device from looking
at /sys/class/uio/uio?/name, I'm not sure how a rename is going to make
any difference.

If you need to poke at uio private data, you are almost certainly doing
something wrong.

Re: UIO device name

[Hans J. Koch]

On Wed, Sep 24, 2008 at 11:57:59AM +0200, Joakim Tjernlund wrote:
> On Wed, 2008-09-24 at 18:35 +0900, Paul Mundt wrote:
> > On Wed, Sep 24, 2008 at 11:21:33AM +0200, Joakim Tjernlund wrote:
> > > As far as I can see there isn't a way to name the /dev/uio%d device file
> > > to something more useful, is that so?
> > > I would like to name the device file from within the kernel so I can
> > > find the correct device from userspace.
> > > The very least is to control the minor(%d) number.
> > > 
> > You have a couple of options for this:
> > 
> > 	- the 'name' sysfs entry for each of the uio devices, which
> > 	  corresponds to the uio device name.
> > 	- extracting the relevant data from things like 'lsuio'.
> > 	- hooking in the pretty mame through udev to create an alias.
> 
> Right, but I want to do it from within the kernel when I create the
> device because that the only place I truly know what HW the uio maps to.

Set info->name to something that's useful for the userspace part of the
driver. You can create an individual string for each HW so userspace can
easily identify the devices. The string in info->name can be anything
you like, it's only used as info given in the "name" sysfs file.

> 
> I found that this works:
>  struct uio_info *info,
>  struct uio_device *idev;
> 
>  idev = info->uio_dev;
>  device_rename(idev->dev, "irq4");
> 
> but then I have to copy the private uio_device struct from uio.c

That's a clear sign that the UIO authors didn't want people to do that
;-)

> Is there a better way to get at idev->dev?

No hackery, please. The "name" attribute is there for this purpose, use
it. Or use one of the other possibilities Paul mentioned.

Thanks,
Hans

Re: UIO device name

[Joakim Tjernlund]

On Wed, 2008-09-24 at 12:22 +0200, Hans J. Koch wrote:
> On Wed, Sep 24, 2008 at 11:57:59AM +0200, Joakim Tjernlund wrote:
> > On Wed, 2008-09-24 at 18:35 +0900, Paul Mundt wrote:
> > > On Wed, Sep 24, 2008 at 11:21:33AM +0200, Joakim Tjernlund wrote:
> > > > As far as I can see there isn't a way to name the /dev/uio%d device file
> > > > to something more useful, is that so?
> > > > I would like to name the device file from within the kernel so I can
> > > > find the correct device from userspace.
> > > > The very least is to control the minor(%d) number.
> > > > 
> > > You have a couple of options for this:
> > > 
> > > 	- the 'name' sysfs entry for each of the uio devices, which
> > > 	  corresponds to the uio device name.
> > > 	- extracting the relevant data from things like 'lsuio'.
> > > 	- hooking in the pretty mame through udev to create an alias.
> > 
> > Right, but I want to do it from within the kernel when I create the
> > device because that the only place I truly know what HW the uio maps to.
> 
> Set info->name to something that's useful for the userspace part of the
> driver. You can create an individual string for each HW so userspace can
> easily identify the devices. The string in info->name can be anything
> you like, it's only used as info given in the "name" sysfs file.

All suggestions so far implies changes i 3 different areas, the kernel
needs to set a name, then udev(I am using mdev btw so that won't work
for me) or add some RC scripts to translate the name to the
wanted /dev/name and then the app needs to know the name.

The udev/scripts is pure overhead and makes it harder for me to have a
generic root FS. I don't see why not uio can offer the kernel to
select another name than the standard uio%d name.

> 
> > 
> > I found that this works:
> >  struct uio_info *info,
> >  struct uio_device *idev;
> > 
> >  idev = info->uio_dev;
> >  device_rename(idev->dev, "irq4");
> > 
> > but then I have to copy the private uio_device struct from uio.c
> 
> That's a clear sign that the UIO authors didn't want people to do that
> ;-)
> 
> > Is there a better way to get at idev->dev?
> 
> No hackery, please. The "name" attribute is there for this purpose, use
> it. Or use one of the other possibilities Paul mentioned.

Yes, this is a hack until UIO has a proper API for choosing a name other
than uio%d. Seems like it is very essy to do, just pass the wanted name
to __uio_register_device() and offer an new uio_register_device_name()
method or add a dev_name field to struct uio_info.

  Jocke

Re: UIO device name

[Paul Mundt]

On Wed, Sep 24, 2008 at 01:33:01PM +0200, Joakim Tjernlund wrote:
> On Wed, 2008-09-24 at 12:22 +0200, Hans J. Koch wrote:
> > Set info->name to something that's useful for the userspace part of the
> > driver. You can create an individual string for each HW so userspace can
> > easily identify the devices. The string in info->name can be anything
> > you like, it's only used as info given in the "name" sysfs file.
> 
> All suggestions so far implies changes i 3 different areas, the kernel
> needs to set a name, then udev(I am using mdev btw so that won't work
> for me) or add some RC scripts to translate the name to the
> wanted /dev/name and then the app needs to know the name.
> 
> The udev/scripts is pure overhead and makes it harder for me to have a
> generic root FS. I don't see why not uio can offer the kernel to
> select another name than the standard uio%d name.
> 
You are seriously arguing about the overhead of creating a symlink based
on name lookup in a sysfs directory? Well, good luck with that.

Your 3-point argument doesn't parse either. With your rename scheme, the
kernel has to set the name in the rename, _and_ your application has to
know the name anyways. So the only difference is that you have to write
some scripts to take care of setting up the link. This is precisely a
single change over your current scheme of trying to rename stuff in the
kernel, and as a bonus, you don't automatically blow up all of the
userspace UIO tools that depend on the uio%d naming.

> > No hackery, please. The "name" attribute is there for this purpose, use
> > it. Or use one of the other possibilities Paul mentioned.
> 
> Yes, this is a hack until UIO has a proper API for choosing a name other
> than uio%d. Seems like it is very essy to do, just pass the wanted name
> to __uio_register_device() and offer an new uio_register_device_name()
> method or add a dev_name field to struct uio_info.
> 
Nonsense, there is nothing wrong with UIO's interface as it is today.
It is no different from sound cards, cdroms, and so on. If you want the
pretty name association and consistent numbering, you use udev. If udev
is too heavy for you, then you hack together some scripts or fix up your
udev-replacement so it's actually useful for normal use. This is not the
kernel's problem, all of the information you need is available to you.
The fact you want to do this in the kernel instead of userspace is
irrelevant. We are not going to add to the kernel data structures because
you don't want to write a one line script.

Re: UIO device name

[Joakim Tjernlund]

On Wed, 2008-09-24 at 20:47 +0900, Paul Mundt wrote:
> On Wed, Sep 24, 2008 at 01:33:01PM +0200, Joakim Tjernlund wrote:
> > On Wed, 2008-09-24 at 12:22 +0200, Hans J. Koch wrote:
> > > Set info->name to something that's useful for the userspace part of the
> > > driver. You can create an individual string for each HW so userspace can
> > > easily identify the devices. The string in info->name can be anything
> > > you like, it's only used as info given in the "name" sysfs file.
> > 
> > All suggestions so far implies changes i 3 different areas, the kernel
> > needs to set a name, then udev(I am using mdev btw so that won't work
> > for me) or add some RC scripts to translate the name to the
> > wanted /dev/name and then the app needs to know the name.
> > 
> > The udev/scripts is pure overhead and makes it harder for me to have a
> > generic root FS. I don't see why not uio can offer the kernel to
> > select another name than the standard uio%d name.
> > 
> You are seriously arguing about the overhead of creating a symlink based
> on name lookup in a sysfs directory? Well, good luck with that.

you wish :) We have a generic FS for lots of different boards so this
script isn't just name lookup. Each board has different needs so the
script needs to be a bit more smart than that and it needs to be updated
each time a new board is added that doesn't fit the current template.

> 
> Your 3-point argument doesn't parse either.

How so? 3 points becomes 2, just the kernel and the app.

>  With your rename scheme, the
> kernel has to set the name in the rename, _and_ your application has to
> know the name anyways. So the only difference is that you have to
> write
> some scripts to take care of setting up the link. This is precisely a
> single change over your current scheme of trying to rename stuff in the
> kernel, and as a bonus, you don't automatically blow up all of the
> userspace UIO tools that depend on the uio%d naming.

Breaking UIO tools isn't ideal, but it would only break for me.
Secondly, you just said the tools are borken already since they
depend on the uio%d numbering instead of looking into /sys/class/uio,
the very thing you want me to do so the tools don't break. I argue that
you should let the kernel driver choose a suitable name if it wants too
instead of forcing all to use a dummy name.

> 
> > > No hackery, please. The "name" attribute is there for this purpose, use
> > > it. Or use one of the other possibilities Paul mentioned.
> > 
> > Yes, this is a hack until UIO has a proper API for choosing a name other
> > than uio%d. Seems like it is very essy to do, just pass the wanted name
> > to __uio_register_device() and offer an new uio_register_device_name()
> > method or add a dev_name field to struct uio_info.
> > 
> Nonsense, there is nothing wrong with UIO's interface as it is today.
> It is no different from sound cards, cdroms, and so on. If you want the

It is different, cdroms and audio are named differently. If they were
using UIO they would all be named /dev/uio%d.

Consider uio_cif and uio_smx, is it impossible to image that such
devices could use another name such as crypto_smx%d instead?

> pretty name association and consistent numbering, you use udev. If udev
> is too heavy for you, then you hack together some scripts or fix up your
> udev-replacement so it's actually useful for normal use. This is not the
> kernel's problem, all of the information you need is available to you.
> The fact you want to do this in the kernel instead of userspace is
> irrelevant. We are not going to add to the kernel data structures because
> you don't want to write a one line script.

I hope I have proved my point above and that you reconsider.

  Jocke 

Re: UIO device name

[Ben Nizette]

On Wed, 2008-09-24 at 14:38 +0200, Joakim Tjernlund wrote:
> On Wed, 2008-09-24 at 20:47 +0900, Paul Mundt wrote:
> > > 
> > Nonsense, there is nothing wrong with UIO's interface as it is today.
> > It is no different from sound cards, cdroms, and so on. If you want the
> 
> It is different, cdroms and audio are named differently. If they were
> using UIO they would all be named /dev/uio%d.
> 
> Consider uio_cif and uio_smx, is it impossible to image that such
> devices could use another name such as crypto_smx%d instead?
> 

My system does use uio_smx and uio_pdrv, they both appear as /dev/uioX.
This to me is just like having /dev/hda, /dev/hdb rather
than /dev/myrootpartition, /dev/somebackupspace or whatever.  In this
case you do have a /dev/cdrom symlink but it's just that, a symlink set
up by scripts.  The kernel doesn't (and shouldn't) make that naming
decision for you.

My software just walks /sys/class/uio/uioX/name, finds the one which
matches then opens the corresponding device.  No scripts needed, no
in-kernel hackery or policy making, just the interface used as the maker
intended.  What's your problem with this approach?

The only software you need is the software you have anyway, the stuff
which opens the device also discovers which device to open.

	--Ben.

Re: UIO device name

[Joakim Tjernlund]

On Thu, 2008-09-25 at 08:57 +1000, Ben Nizette wrote:
> On Wed, 2008-09-24 at 14:38 +0200, Joakim Tjernlund wrote:
> > On Wed, 2008-09-24 at 20:47 +0900, Paul Mundt wrote:
> > > > 
> > > Nonsense, there is nothing wrong with UIO's interface as it is today.
> > > It is no different from sound cards, cdroms, and so on. If you want the
> > 
> > It is different, cdroms and audio are named differently. If they were
> > using UIO they would all be named /dev/uio%d.
> > 
> > Consider uio_cif and uio_smx, is it impossible to image that such
> > devices could use another name such as crypto_smx%d instead?
> > 
> 
> My system does use uio_smx and uio_pdrv, they both appear as /dev/uioX.
> This to me is just like having /dev/hda, /dev/hdb rather
> than /dev/myrootpartition, /dev/somebackupspace or whatever.  In this
> case you do have a /dev/cdrom symlink but it's just that, a symlink set
> up by scripts.  The kernel doesn't (and shouldn't) make that naming
> decision for you.
> 
> My software just walks /sys/class/uio/uioX/name, finds the one which
> matches then opens the corresponding device.  No scripts needed, no
> in-kernel hackery or policy making, just the interface used as the maker
> intended.  What's your problem with this approach?

My problem is this, uio is a generic container for any user space device
and by itself it doesn't mean much. You put some protocol driver on top
of uio, such as uio_smx, to make it mean something. 

Comparing uio with hdX is wrong as hdX means something, it is a block
device for a disk. 
A better comparison would be if all kernel devices were named kio%d and
you had to scan /sys to find the name hdX.

Look at the spi subsystem, the protocol drivers name them self.

 Jocke

Re: UIO device name

[Ben Nizette]

On Thu, 2008-09-25 at 12:05 +0200, Joakim Tjernlund wrote:
> On Thu, 2008-09-25 at 08:57 +1000, Ben Nizette wrote:
> > 
> > My software just walks /sys/class/uio/uioX/name, finds the one which
> > matches then opens the corresponding device.  No scripts needed, no
> > in-kernel hackery or policy making, just the interface used as the maker
> > intended.  What's your problem with this approach?
> 
> My problem is this, uio is a generic container for any user space device
> and by itself it doesn't mean much. You put some protocol driver on top
> of uio, such as uio_smx, to make it mean something. 
> 
> Comparing uio with hdX is wrong as hdX means something, it is a block
> device for a disk. 
> A better comparison would be if all kernel devices were named kio%d and
> you had to scan /sys to find the name hdX.

UIO drivers certainly aren't first class citizens like kernel mode
drivers.  They just aren't.

> 
> Look at the spi subsystem, the protocol drivers name them self.

UIO is an interface type, not a bus type.  UIO isn't a subsystem as
such, it's a user interface.  If the interface is consistent (even if
the backing device is different) I don't see the problem with consistent
naming.

Anyway, I don't really see the point arguing here - the interface is
what it is, it does everything it needs to to allow you to identify the
device nodes.  The kernel boys have spent a lot of effort over time
letting userspace identify and name device nodes and I don't really see
the difference here :-)

	--Ben.

Re: UIO device name

[Joakim Tjernlund]

On Thu, 2008-09-25 at 20:48 +1000, Ben Nizette wrote:
> On Thu, 2008-09-25 at 12:05 +0200, Joakim Tjernlund wrote:
> > On Thu, 2008-09-25 at 08:57 +1000, Ben Nizette wrote:
> > > 
> > > My software just walks /sys/class/uio/uioX/name, finds the one which
> > > matches then opens the corresponding device.  No scripts needed, no
> > > in-kernel hackery or policy making, just the interface used as the maker
> > > intended.  What's your problem with this approach?
> > 
> > My problem is this, uio is a generic container for any user space device
> > and by itself it doesn't mean much. You put some protocol driver on top
> > of uio, such as uio_smx, to make it mean something. 
> > 
> > Comparing uio with hdX is wrong as hdX means something, it is a block
> > device for a disk. 
> > A better comparison would be if all kernel devices were named kio%d and
> > you had to scan /sys to find the name hdX.
> 
> UIO drivers certainly aren't first class citizens like kernel mode
> drivers.  They just aren't.
> 
> > 
> > Look at the spi subsystem, the protocol drivers name them self.
> 
> UIO is an interface type, not a bus type.  UIO isn't a subsystem as
> such, it's a user interface.  If the interface is consistent (even if
> the backing device is different) I don't see the problem with consistent
> naming.

Do you see a problem with letting the protocol driver choose another
one? Why not offer the user the chance to let the name mean something?

> 
> Anyway, I don't really see the point arguing here - the interface is
> what it is, it does everything it needs to to allow you to identify the
> device nodes.  The kernel boys have spent a lot of effort over time
> letting userspace identify and name device nodes and I don't really see
> the difference here :-)

The changes needed to make it possible to select a different name are
really minimal(include below for 2.6.25). So I ask again, why not let
the driver choose?

>From e58037d887c0432fa16bbb1e9e02b390b11cc758 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Thu, 25 Sep 2008 13:22:53 +0200
Subject: [PATCH] [UIO] Let UIO protocol drivers name them self.

Currently all UIO based drivers will be named "uio%d"
in user space. Make it possible for protocol drivers
to use a different name.
---
 drivers/uio/uio.c          |    4 +++-
 include/linux/uio_driver.h |    2 ++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 1175908..950233f 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -642,10 +642,12 @@ int __uio_register_device(struct module *owner,
 	ret = uio_get_minor(idev);
 	if (ret)
 		goto err_get_minor;
+	if (!info->bus_name)
+		info->bus_name = "uio%d";
 
 	idev->dev = device_create(uio_class->class, parent,
 				  MKDEV(uio_major, idev->minor),
-				  "uio%d", idev->minor);
+				  info->bus_name, idev->minor);
 	if (IS_ERR(idev->dev)) {
 		printk(KERN_ERR "UIO: device register failed\n");
 		ret = PTR_ERR(idev->dev);
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 973386d..c55146a 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -44,6 +44,7 @@ struct uio_device;
  * struct uio_info - UIO device capabilities
  * @uio_dev:		the UIO device this info belongs to
  * @name:		device name
+ * @bus_name:		bus name
  * @version:		device driver version
  * @mem:		list of mappable memory regions, size==0 for end of list
  * @irq:		interrupt number or UIO_IRQ_CUSTOM
@@ -57,6 +58,7 @@ struct uio_device;
 struct uio_info {
 	struct uio_device	*uio_dev;
 	char			*name;
+	char			*bus_name;
 	char			*version;
 	struct uio_mem		mem[MAX_UIO_MAPS];
 	long			irq;
-- 
1.5.6.5

Re: UIO device name

[Paul Mundt]

On Thu, Sep 25, 2008 at 01:41:08PM +0200, Joakim Tjernlund wrote:
> On Thu, 2008-09-25 at 20:48 +1000, Ben Nizette wrote:
> > UIO is an interface type, not a bus type.  UIO isn't a subsystem as
> > such, it's a user interface.  If the interface is consistent (even if
> > the backing device is different) I don't see the problem with consistent
> > naming.
> 
> Do you see a problem with letting the protocol driver choose another
> one? Why not offer the user the chance to let the name mean something?
> 
This thread is still going? Amazing. Anyways, your protocol driver
argument doesn't make any sense. Take the case of uio_pdrv or the genirq
variant. This is the name it hands off to the core, while the devices
that register underneath it all have their own names set. Go grep for all
instances of uio_pdrv platform data in the architecture code. I'm getting
the impression you haven't actually even bothered to look at the name
entries.

Breaking the uio%d stuff is unacceptable, and if you need explanations
for why, then you really shouldn't be touching subsystem code in the
first place. Additionally, so far you haven't been able to show a single
example of something you can't already do with the information in
userspace today. If you want more descriptive names, use udev or symlinks
you kick off from the script.

Re: UIO device name

[Joakim Tjernlund]

On Thu, 2008-09-25 at 20:53 +0900, Paul Mundt wrote:
> On Thu, Sep 25, 2008 at 01:41:08PM +0200, Joakim Tjernlund wrote:
> > On Thu, 2008-09-25 at 20:48 +1000, Ben Nizette wrote:
> > > UIO is an interface type, not a bus type.  UIO isn't a subsystem as
> > > such, it's a user interface.  If the interface is consistent (even if
> > > the backing device is different) I don't see the problem with consistent
> > > naming.
> > 
> > Do you see a problem with letting the protocol driver choose another
> > one? Why not offer the user the chance to let the name mean something?
> > 
> This thread is still going? Amazing. Anyways, your protocol driver
> argument doesn't make any sense. Take the case of uio_pdrv or the genirq
> variant. This is the name it hands off to the core, while the devices
> that register underneath it all have their own names set. Go grep for all
> instances of uio_pdrv platform data in the architecture code. I'm getting
> the impression you haven't actually even bothered to look at the name
> entries.

Thanks for your kind words. It is true that I am not an expert in this
area, just trying to understand and improve. Obviously I still lack 
some knowledge but now I am done with uio's interface naming, I will
just scan sysfs for it. 

 Jocke