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

[ message continues ]

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

[ message continues ]

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

--

[ message continues ]

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

[ message continues ]

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

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

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

Thanks,
Hans

--

[ message continues ]

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

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

[ message continues ]

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

[ message continues ]

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


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

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

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

  Jocke 

--

[ message continues ]

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.


--

[ message continues ]

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

[ message continues ]

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

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.


--

[ message continues ]

Do you see a problem with letting the protocol driver choose another

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


--

[ message continues ]

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

[ message continues ]

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

[ message continues ]