Which node has the device been bound to?

Kim Deokhwan <kd <at> atropos.snu.ac.kr>
2002-05-29 10:23:34 GMT

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

Re: Which node has the device been bound to?

Greg KH <greg <at> kroah.com>
2002-05-31 18:26:15 GMT

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

Re: Which node has the device been bound to?

Dmitri <dmitri <at> users.sourceforge.net>
2002-05-31 17:12:46 GMT

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.

PCI Hot Plug Operation

Bill Bruce <bill_bruce <at> terago.com>
2002-05-03 16:00:10 GMT

My situation:
The software base is Redhat 7.2. The kernel has been updated to 2.4.9. The
user-space hot plug files/scripts dated 2002_4_1 from SourceForge have been
installed.
I install a PCI card in my system and power it up. It appears on the PCI bus
(lspci -H1 confirms this).
There is no driver for this card in the kernel, but according to my reading
of the hot plug documentation I expect the /sbin/hotplug script to be
invoked, giving me an opportunity to load a driver. This is not happening.
Some rudimentary questions:
I am assuming the kernel is periodically scanning the PCI bus, looking for
new devices. Is this correct? If so how often does this happen?
Do I need to install a driver for my card to make the kernel aware of a
possible hot pluggable device?
Thanks
Bill Bruce
Terago Communications
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net

Re: PCI Hot Plug Operation

Greg KH <greg <at> kroah.com>
2002-05-03 15:16:25 GMT

On Fri, May 03, 2002 at 11:00:10AM -0500, Bill Bruce wrote:
> My situation:
>
> The software base is Redhat 7.2. The kernel has been updated to 2.4.9. The
> user-space hot plug files/scripts dated 2002_4_1 from SourceForge have been
> installed.
>
> I install a PCI card in my system and power it up. It appears on the PCI bus
> (lspci -H1 confirms this).
>
> There is no driver for this card in the kernel, but according to my reading
> of the hot plug documentation I expect the /sbin/hotplug script to be
> invoked, giving me an opportunity to load a driver. This is not happening.
/sbin/hotplug is not envoked at the first scanning of the PCI bus. This
might be considered a bug, but as there is no userspace set up at this
point in time, any call out to /sbin/hotplug would not work anyway :)
This will be fixed in 2.5, when we have initramfs working.
> Some rudimentary questions:
>
> I am assuming the kernel is periodically scanning the PCI bus, looking for
> new devices. Is this correct? If so how often does this happen?
No, this is not happening.
> Do I need to install a driver for my card to make the kernel aware of a
> possible hot pluggable device?

Re: PCI Hot Plug Operation

David Brownell <david-b <at> pacbell.net>
2002-05-06 17:16:08 GMT

> > Do I need to install a driver for my card to make the kernel aware of a
> > possible hot pluggable device?
>
> PCI Hotplug only works if you have a PCI Hotplug controller on your
> motherboard. This is usually only on high end servers or cPCI machines.
> Do you have such a machine?
Erm, when did that change?
There might be confusion about the several different types of PCI hotplug
that can happen. It started out as a generic term in Linux, not specific
to a specific technology.
- The original Linux PCI hotplug support worked well for CardBus.
Plug in a new CardBus device ("PC-Card" form factor with PCI
bus, often mis-termed PCMCIA) and get a hotplug event.
- Docking station support ... I'm not clear what the status here
is, but some of them support CardBus, so they should inherit
a certain level of hotplug support from that.
- Compaq's "PCI Hotplug" support is, as Greg said, for higher
end hardware ... aiming at "more nines than usual" availability.
- The "Compact PCI" stuff is a different form factor (VME?) that
is likewise targetted at high availability applications, where it
is not practical to take systems down to reconfigure hardware.
Admittedly you need to configure the support for those kinds of
bus into your system, but "/sbin/hotplug pci" can be invoked without

Re: PCI Hot Plug Operation

Greg KH <greg <at> kroah.com>
2002-05-06 16:32:12 GMT

On Mon, May 06, 2002 at 10:16:08AM -0700, David Brownell wrote:
> > > Do I need to install a driver for my card to make the kernel aware of a
> > > possible hot pluggable device?
> >
> > PCI Hotplug only works if you have a PCI Hotplug controller on your
> > motherboard. This is usually only on high end servers or cPCI machines.
> > Do you have such a machine?
>
> Erm, when did that change?
>
> There might be confusion about the several different types of PCI hotplug
> that can happen. It started out as a generic term in Linux, not specific
> to a specific technology.
<snip>
Good clarification here, sorry about that. I was thinking about the
"PCI Hotplug Support" as the "PCI Hotplug Spec" describes it, as that's
what I deal with all day long at my job.
Again, sorry for any confusion.
thanks,
greg k-h
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net

Re: PCI Hot Plug Operation

Paul Hedderly <paul <at> mjr.org>
2002-05-04 08:33:23 GMT

On Fri, May 03, 2002 at 08:16:25AM -0700, Greg KH wrote:
> PCI Hotplug only works if you have a PCI Hotplug controller on your
> motherboard. This is usually only on high end servers or cPCI machines.
> Do you have such a machine?
Well, there are other machines that pci hotplug could work on - laptops.
Many have docking stations that add an extra pci bus through a bridge...
it would be really nice to be able to "hot" add that bus, and "hot"
remove it - provided devices on it were not in use.
The IBM laptops do this very well, but I don't think linux supports this
kind of functionality... yet? Is it possible? Is anyone working on it?
--
Cheers
Paul
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net

Re: PCI Hot Plug Operation

David Woodhouse <dwmw2 <at> infradead.org>
2002-05-04 08:57:47 GMT

paul <at> mjr.org said:
> Many have docking stations that add an extra pci bus through a
> bridge... it would be really nice to be able to "hot" add that bus,
> and "hot" remove it - provided devices on it were not in use.
If you remove the laptop from the docking station, the PCI devices are no
longer in use. Whether you like it or not.
--
dwmw2
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth <at> sourceforge.net