Which node has the device been bound to?

Which node has the device been bound to?

[Kim Deokhwan]

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?

Thanks.

--
Kim Deokhwan

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Oliver Neukum]

Am Mittwoch, 29. Mai 2002 12:23 schrieb Kim Deokhwan:
> 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?

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.

You might have a look at driverfs currently under development in the
2.5 tree. It could help.

In addition the hotplug script may be called without a loaded driver
and there'll be no notification (outside devfs) if a driver binds to a device
after the device is plugged in.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Dmitri]

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

On Sun, 2002-06-02 at 08:21, Oliver Neukum wrote:
> Am Mittwoch, 29. Mai 2002 12:23 schrieb Kim Deokhwan:
> > 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?
> 
> 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.

You need to tell the difference between the hardware devices, and you
need to know which identified device uses which device node.

Both can be done if the serial driver creates its own /proc/xxx entries.
It is quite simple, and can be easily added. Some webcams, for example,
offer this functionality for their own purposes. This will work on 2.4
kernel. The driver would, for example, create a text "file" (generated
with a callback within the driver), and each line of text would contain
serial number of the device (or hash of its descriptors) and the device
node ID.

Synchronization is, of course, a concern, since devices can be unplugged
and replugged, but if you read the file immediately before opening the
device it should be reasonably OK - users are not *that* fast ;-) You
can also reread the file after opening the device and verify that it
hasn't changed while you were blocked on open() call.

Dmitri


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Which node has the device been bound to?

[Greg KH]

On Wed, May 29, 2002 at 07:23:34PM +0900, Kim Deokhwan wrote:
> 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?

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?

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Oliver Neukum]

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

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

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Greg KH]

On Sat, Jun 01, 2002 at 02:05:25AM +0200, Oliver Neukum wrote:
> 
> > > 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.
> >
> > 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 ?

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

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

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

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Oliver Neukum]

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

Oh well.

> > > 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 ?
>
> Have you seen the way driverfs shows the usb and pci topology?

Fine for humans, which is not the issue here.

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

	Regards
		Oliver

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Greg KH]

On Sat, Jun 01, 2002 at 04:12:47AM +0200, Oliver Neukum wrote:
> > Have you seen the way driverfs shows the usb and pci topology?
> 
> Fine for humans, which is not the issue here.

And for programs.

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

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

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

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Oliver Neukum]

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

Nope. You had opened the device. The name changes meaning.
The fd does not.

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

Ioctl() works atomic. If locks are needed, the ioctl() handler can safely
implement them.

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

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Greg KH]

On Mon, Jun 03, 2002 at 11:09:36PM +0200, Oliver Neukum wrote:
> > 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?

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Oliver Neukum]

Am Montag, 3. Juni 2002 23:58 schrieb Greg KH:
> On Mon, Jun 03, 2002 at 11:09:36PM +0200, Oliver Neukum wrote:
> > > 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?

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.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Greg KH]

On Tue, Jun 04, 2002 at 12:43:38AM +0200, Oliver Neukum wrote:
> Am Montag, 3. Juni 2002 23:58 schrieb Greg KH:
> > On Mon, Jun 03, 2002 at 11:09:36PM +0200, Oliver Neukum wrote:
> > > > 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?
> 
> 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 think you are correct, that's why I asked.

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

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

I saw a patch to driverfs that did this a while ago, but see Linus's
comments on lkml about why this will probably never happen.

thanks

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Oliver Neukum]

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

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Greg KH]

On Tue, Jun 04, 2002 at 01:05:09AM +0200, Oliver Neukum wrote:
> 
> > > 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.

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.

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Oliver Neukum]

Am Dienstag, 4. Juni 2002 01:16 schrieb Greg KH:
> On Tue, Jun 04, 2002 at 01:05:09AM +0200, Oliver Neukum wrote:
> > > > 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.
>
> 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.

	Regards
		Oliver


_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[Greg KH]

On Tue, Jun 04, 2002 at 01:37:13AM +0200, Oliver Neukum wrote:
> Am Dienstag, 4. Juni 2002 01:16 schrieb Greg KH:
> > On Tue, Jun 04, 2002 at 01:05:09AM +0200, Oliver Neukum wrote:
> > > > > 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.
> >
> > 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.

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.

> IMHO this defeats the purpose.

What purpose?  driverfs?  driverfs is for a system-wide driver topology,
and to provide a driver specific place for driver specific interface
files (instead of /proc).  And it meets that purpose quite well.

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

thanks,

greg k-h

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: Which node has the device been bound to?

[David Brownell]

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

FWIW I do think it'd be worth making it easier (in 2.5) for drivers to
use stable physical device IDs ... since those are the only IDs that always
exist.  Not every device has a unique label (FS, MAC, serial, etc), but
even given hotplugging, at a given moment a given physical/topological ID
refers to only one device.

We have such IDs already, in most subsystems.  What we don't have is ways
to go from physical ID to logical (char/block major+minor, or whatever)
IDs, and back.  Historically, that kind of thing has always been done
using ioctls on open files.  Defining such IOCTLs, and teaching the various
driver frameworks to use them, has no particular technical challenges.
(Politics may be a different issue.  Easier for each subsystem to have
its own ioctls -- like ethtool -- than unify all drivers...)



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

On the other hand, the hotplug framework certainly does need to have
some solution to the "hands-off no-adminstrator configuration" problems
to meet its basic usability goals (except some parts of enterprise
configurations).

That is, while I agree that the problem isn't just a hotplugging issue
(hotplugging wasn't created to solve that) I don't agreee with the
implication that it's even slightly offtopic.

(Part of this is actually "device discovery":  finding out what CDs,
cameras, mice, etc are connected.  Another part is "device announcement",
a level up from loading the right driver module:  configuring that
printer or network link, mounting disk partitions, and so on.)



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

Hardly!  On the other hand, that's always been a bug from the perspective
of being able to do hands-off configuration.  Call it an RFE if you want,
but that kind of capability is essential for broader uses of Linux:  we
can't expect every K-12 or home user to be (or have access) to a Linux
sysadmin, and we know the "every vendor does their own sysadmin tools"
approach doesn't work, just from seeing it fail so thoroughly for all
the classic UNIX vendors.

- Dave




_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel