Which node has the device been bound to?

Within a USB policy agent script, can we tell precisely which node the device has been bound to? According to Documentation/usb/usb-serial.txt:

When the device is connected and recognized by the driver, the driver will print to the system log, which node(s) the device has been bound to.

But the log message is too succint:

  May 27 10:51:11 localhost kernel: usbserial.c: Compaq iPAQ converter
  now attached to ttyUSB0 (or usb/tts/0 for devfs)

In case of one iPAQ, we can find the relevant log entry by grepping the LAST matched line. But if two iPAQs are attached nearly at the same time, the last matched line may not be the relevant entry because context switching may happen between two agent scripts.

Do you have any method that can solve it?

Am Mittwoch, 29. Mai 2002 12:23 schrieb Kim Deokhwan:

Quoted 18 lines

Within a USB policy agent script, can we tell precisely which node the device has been bound to? According to Documentation/usb/usb-serial.txt:

When the device is connected and recognized by the driver, the driver will print to the system log, which node(s) the device has been bound to.

But the log message is too succint:

  May 27 10:51:11 localhost kernel: usbserial.c: Compaq iPAQ converter
  now attached to ttyUSB0 (or usb/tts/0 for devfs)

In case of one iPAQ, we can find the relevant log entry by grepping the LAST matched line. But if two iPAQs are attached nearly at the same time, the last matched line may not be the relevant entry because context switching may happen between two agent scripts.

Quoted 1 line

Do you have any method that can solve it?

At present I am afraid not.
This is just the tip of the iceberg. Basically, even if you had that type of information, you cannot be sure that it stays valid while the script is running.

Within a USB policy agent script, can we tell precisely which node the device has been bound to? According to Documentation/usb/usb-serial.txt:

When the device is connected and recognized by the driver, the driver will print to the system log, which node(s) the device has been bound to.

But the log message is too succint:

  May 27 10:51:11 localhost kernel: usbserial.c: Compaq iPAQ converter
  now attached to ttyUSB0 (or usb/tts/0 for devfs) 

In case of one iPAQ, we can find the relevant log entry by grepping the LAST matched line. But if two iPAQs are attached nearly at the same time, the last matched line may not be the relevant entry because context switching may happen between two agent scripts.

Do you have any method that can solve it?

Quoted 6 lines

In case of one iPAQ, we can find the relevant log entry by grepping the LAST matched line. But if two iPAQs are attached nearly at the same time, the last matched line may not be the relevant entry because context switching may happen between two agent scripts.

Quoted 1 line

Do you have any method that can solve it?

Right now, no, sorry.

In the 2.5 tree, the usbserial driver creates a /proc/tty/driver/usbserial file that allows you to see all of the different usbserial devices currently connected to the system, but it doesn't really help you in determining which iPAQ is which.

The driverfs changes that are slowly going into the tree might eventually help you out. Check out the changes that will be in 2.5.20 for the usb tree (they look much like the pci tree in 2.5.19 if you want to compare that right now.)

And how would you be able to determine uniquely each iPAQ anyway? Do they have unique USB serial numbers or would you want to determine the device based on the physical USB port it is plugged into on the host?

Quoted 10 lines

Quoted 7 lines

In case of one iPAQ, we can find the relevant log entry by grepping the LAST matched line. But if two iPAQs are attached nearly at the same time, the last matched line may not be the relevant entry because context switching may happen between two agent scripts.

Do you have any method that can solve it?

Right now, no, sorry.

Quoted 4 lines

In the 2.5 tree, the usbserial driver creates a /proc/tty/driver/usbserial file that allows you to see all of the different usbserial devices currently connected to the system, but it doesn't really help you in determining which iPAQ is which.

Do you think that it's wise to introduce yet another driver specific file ?

Quoted 8 lines

The driverfs changes that are slowly going into the tree might eventually help you out. Check out the changes that will be in 2.5.20 for the usb tree (they look much like the pci tree in 2.5.19 if you want to compare that right now.)

And how would you be able to determine uniquely each iPAQ anyway? Do they have unique USB serial numbers or would you want to determine the device based on the physical USB port it is plugged into on the host?

You might not like it, but I still think that a standard ioctl() would be the best way to export such information. Could you enlighten me on how you want to make sure that the information you act on is guaranteed to be current, if you do not base the mechanism on the opened device ?

Quoted 3 lines

Do you think that it's wise to introduce yet another driver specific file ?

Not really, but it follows the way _all_ other tty drivers do it :)

Quoted 9 lines

Quoted 8 lines

The driverfs changes that are slowly going into the tree might eventually help you out. Check out the changes that will be in 2.5.20 for the usb tree (they look much like the pci tree in 2.5.19 if you want to compare that right now.)

And how would you be able to determine uniquely each iPAQ anyway? Do they have unique USB serial numbers or would you want to determine the device based on the physical USB port it is plugged into on the host?

Quoted 5 lines

You might not like it, but I still think that a standard ioctl() would be the best way to export such information. Could you enlighten me on how you want to make sure that the information you act on is guaranteed to be current, if you do not base the mechanism on the opened device ?

Have you seen the way driverfs shows the usb and pci topology?

And yes, you might be acting on old data. But if you have an ioctl() what would it return? A pointer to the topology location which might have just changed? I don't see how an ioctl() can solve this problem any different from the way driverfs is going about it. But I could be missing something. :)

Quoted 1 line

Have you seen the way driverfs shows the usb and pci topology?

Fine for humans, which is not the issue here.

Quoted 5 lines

And yes, you might be acting on old data. But if you have an ioctl() what would it return? A pointer to the topology location which might have just changed? I don't see how an ioctl() can solve this problem any different from the way driverfs is going about it. But I could be missing something. :)

An ioctl() would either return the actual topology information or a unique token.

A name can change meaning. An open file cannot. It'll either be what the ioctl() will tell you, or it'll be gone. If you operate on a device that is gone the kernel will return an error and all is well.

If you parse what driverfs gives you, you operate on changing data without a lock. I can see no way to change that.

Quoted 4 lines

A name can change meaning. An open file cannot. It'll either be what the ioctl() will tell you, or it'll be gone. If you operate on a device that is gone the kernel will return an error and all is well.

Yes, you get a response from an ioctl that points you to a /dev node or a driverfs file. Then the device is disconnected and whatever you had pointing to that device (the /dev file pointer) is replaced with a new device connecting. Same problem as before :)

Quoted 2 lines

If you parse what driverfs gives you, you operate on changing data without a lock. I can see no way to change that.

I don't see a way around this even with ioctl().

But what is the real problem here? What do you want to solve? Mapping of a /dev node to a physical device? Or mapping of a physical device to a /dev node? Or something else?

Quoted 3 lines

But what is the real problem here? What do you want to solve? Mapping of a /dev node to a physical device? Or mapping of a physical device to a /dev node? Or something else?

The former. The latter has some principal problems.
To do the former you need to have an atomic operation on an opened device.
Thus you need to have the device node open and you need
the ioctl to not return a pointer to a driverfs file. You either return its content or an fd.

Quoted 10 lines

Quoted 3 lines

But what is the real problem here? What do you want to solve? Mapping of a /dev node to a physical device? Or mapping of a physical device to a /dev node? Or something else?

The former. The latter has some principal problems.
To do the former you need to have an atomic operation on an opened device.
Thus you need to have the device node open and you need the ioctl to not return a pointer to a driverfs file. You either return its content or an fd.

Ok, I understand a bit better now (sorry, I'm slow today...). So what fd do you want returned in the ioctl()? driverfs implements a tree for every device, not a single file. Do you want a fd for the directory?

Am Montag, 3. Juni 2002 23:58 schrieb Greg KH:

Quoted 12 lines · Oliver Neukum

Quoted 10 lines

Quoted 3 lines

But what is the real problem here? What do you want to solve? Mapping of a /dev node to a physical device? Or mapping of a physical device to a /dev node? Or something else?

The former. The latter has some principal problems.
To do the former you need to have an atomic operation on an opened device.
Thus you need to have the device node open and you need the ioctl to not return a pointer to a driverfs file. You either return its content or an fd.

Quoted 3 lines

Ok, I understand a bit better now (sorry, I'm slow today...). So what fd do you want returned in the ioctl()? driverfs implements a tree for every device, not a single file. Do you want a fd for the directory?

No problem, I am dense at times, too.
There's a problem. You cannot open() based on a directory fd, unless I am mistaken.

I can't come up with anything better than a set of ioctls that return the contents of the individual files. And I know that this is ugly. I don't claim that this is a good solution, just that it's the only solution I have and that there's a race otherwise.
You simply cannot use names, thus parsing files for the name of the node won't work.

I've thought about finding the device node to a physical device. It really is problematic. Firstly there can be several nodes. Secondly you'd need device nodes in driverfs, in effect merging it with devfs.

Quoted 7 lines

I can't come up with anything better than a set of ioctls that return the contents of the individual files. And I know that this is ugly. I don't claim that this is a good solution, just that it's the only solution I have and that there's a race otherwise.
You simply cannot use names, thus parsing files for the name of the node won't work.

Or we could just drop the whole idea of using ioctl() and live with the "instability" of parsing a filesystem :)

Quoted 8 lines

Quoted 7 lines

I can't come up with anything better than a set of ioctls that return the contents of the individual files. And I know that this is ugly. I don't claim that this is a good solution, just that it's the only solution I have and that there's a race otherwise.
You simply cannot use names, thus parsing files for the name of the node won't work.

Quoted 2 lines

Or we could just drop the whole idea of using ioctl() and live with the "instability" of parsing a filesystem :)

There is no such thing is an acceptable race condition.

Quoted 10 lines

Quoted 9 lines

Quoted 6 lines

I can't come up with anything better than a set of ioctls that return the contents of the individual files. And I know that this is ugly. I don't claim that this is a good solution, just that it's the only solution I have and that there's a race otherwise. You simply cannot use names, thus parsing files for the name of the node won't work.

Or we could just drop the whole idea of using ioctl() and live with the "instability" of parsing a filesystem :)

Quoted 1 line

There is no such thing is an acceptable race condition.

Then use the device tree in driverfs as a "hint" as to where you might find your device. Then rely on other things (fs labels, usb serial numbers, ethernet mac addresses, etc.) to verify if the device you are talking to really is the one you think it is.

Am Dienstag, 4. Juni 2002 01:16 schrieb Greg KH:

Quoted 13 lines · Oliver Neukum

Quoted 11 lines

Quoted 9 lines

Quoted 6 lines

I can't come up with anything better than a set of ioctls that return the contents of the individual files. And I know that this is ugly. I don't claim that this is a good solution, just that it's the only solution I have and that there's a race otherwise. You simply cannot use names, thus parsing files for the name of the node won't work.

Or we could just drop the whole idea of using ioctl() and live with the "instability" of parsing a filesystem :)

There is no such thing is an acceptable race condition.

Quoted 4 lines

Then use the device tree in driverfs as a "hint" as to where you might find your device. Then rely on other things (fs labels, usb serial numbers, ethernet mac addresses, etc.) to verify if the device you are talking to really is the one you think it is.

The project started out to solve the problem once and forever and now we are back at several heuristics.

IMHO this defeats the purpose.

Quoted 4 lines

Quoted 4 lines

Then use the device tree in driverfs as a "hint" as to where you might find your device. Then rely on other things (fs labels, usb serial numbers, ethernet mac addresses, etc.) to verify if the device you are talking to really is the one you think it is.

Quoted 2 lines

The project started out to solve the problem once and forever and now we are back at several heuristics.

Wait, what project? linux-hotplug was created to "solve" the initial problem of people calling /sbin/hotplug in different ways, which broke userspace tools. It then became a forum for the linux-hotplug package, and general hotplugging issues.

It was never created to solve "the hotplugging/device naming/persistent path/fish slicing and dicing" problem.

Just because we can't uniquely, and race-free identify a device node with a physical device (either mapping, you choose) doesn't mean all is lost. We've never been able to do that :)