general hotplug/udev questions

general hotplug/udev questions

[rich turner]

i am looking at the way suse 9.3 is using hotplug and udev to load
network device modules, and want to know if this is specific to suse or
if hotplug/udev is using this method and will be used by other
distributions going forward.

keep in mind that i am not using the initrd (which is initramfs) that
suse distributes, or their mkinitrd to create it. i have a process that
creates an initrd (old-school, not initramfs), which works on any
distribution (2.4 and 2.6 kernels).

my problem is that my network modules are not being loaded when the
system boots. on all previous distibutions it was a matter of adding the
network devices as an alias in /etc/modprobe.conf and then the network
startup scripts would handle loading the module when the device was
brought up:
alias eth0 sis900

what i am seeing on suse 9.3 is that in their initrd (initramfs) they
are using klibc and are echoing /sbin/hotplug.sh
to /proc/sys/kernel/hotplug. this is the contents of /sbin/hotplug.sh:

#!/bin/sh
#
# /sbin/hotplug.sh
# $Id: hotplug.sh,v 1.1 2005/01/20 10:38:11 hare Exp $
#
# Simple hotplug script for initramfs
# Records all events if requested and starts up udev
#
# Records all events if requested
if [ -d /events -a -x /sbin/hotplugeventrecorder ] ; then
    /sbin/hotplugeventrecorder $1 2>/dev/null
fi
AGENT=/sbin/udev
if [ -x $AGENT ]; then
    exec $AGENT $@
    echo "couldn't exec $AGENT"
fi
exit 1

they will then copy all entries that are created in /events
to /lib/klibc/events and mount it up using tmpfs so they can access them
when exiting the initrd.

then within their boot.coldplug init script, they take those events and
load the modules.

because my linuxrc does not create events or mount /lib/klibc/events in
the initrd, then boot.coldplug does not load the network modules.

i realize i can load the network modules in the initrd and everything
would be golden, but that is not the purpose of the initrd. in my
opinion we already do to much in the initrd because the distributions
dont do enough (or do it correctly) in their init scripts. we try to
keep the initrd's purpose to do only enough to mount the root
filesystem.

it is important that our process remain generic across all distributions
because we need to support many other distributions.

does anyone have an opinion as to whether suse's current method will
become the standard?

it appears that udevstart.static creates events but /sbin/udevstart does
not. why is that?

is /sbin/hotplugevenrecorder an executable being distributed by suse or
is it something that will be coming in the maintained udev?

even though we use udevstart in the initrd, is there any real purpose to
echoing something (/sbin/udev, /sbin/udevsend, /bin/true) out
to /proc/sys/kernel/hotplug while in the initrd?

it is my experience that udev only handles devices that you would expect
to find in /dev. how could it have any effect on network interfaces? is
this a product of hotplug or udev?

i apologize for the long message, but i do appreciate any feedback.

rich turner



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Greg KH]

On Thu, Aug 18, 2005 at 12:53:34PM -0700, rich turner wrote:
> because my linuxrc does not create events or mount /lib/klibc/events in
> the initrd, then boot.coldplug does not load the network modules.

That is correct.

> i realize i can load the network modules in the initrd and everything
> would be golden, but that is not the purpose of the initrd. in my
> opinion we already do to much in the initrd because the distributions
> dont do enough (or do it correctly) in their init scripts. we try to
> keep the initrd's purpose to do only enough to mount the root
> filesystem.

Sorry, but that's not the way we are all moving toward.  With initramfs
and kinit we are pushing more and more of the early boot stuff into a
initramfs/initrd image to get it out of the kernel itself.

> it is important that our process remain generic across all distributions
> because we need to support many other distributions.

I wish you the best of luck.  Providing custom kernel images for
different distros, while ignoring how they do their initrd/initramfs
boot sequence seems like a futile way to go.  Not to mention breaking
your customer's service contracts with their distro :)

> does anyone have an opinion as to whether suse's current method will
> become the standard?

Is there ever a "standard" for Linux?  :)

Seriously, I think something like this will become more common as it
solves a lot of problems people have with early boot processes.  Look at
how Red Hat solves it (in a different way, but with the same results.)

> it appears that udevstart.static creates events but /sbin/udevstart does
> not. why is that?
> 
> is /sbin/hotplugevenrecorder an executable being distributed by suse or
> is it something that will be coming in the maintained udev?

http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hš3c3e197c6cf3972c0f9d910ac206aed3df66e7;hbŒ11a2f0ff27264513033691bb818262f009fe4e;f=udeveventrecorder.c
look like what you are looking for?

> even though we use udevstart in the initrd, is there any real purpose to
> echoing something (/sbin/udev, /sbin/udevsend, /bin/true) out
> to /proc/sys/kernel/hotplug while in the initrd?

Depends on how you want to catch hotplug events.

Note, a lot of this has changed recently in suse's kernel.  Take a look
at opensuse beta 2 for examples of this.

> it is my experience that udev only handles devices that you would expect
> to find in /dev. how could it have any effect on network interfaces? is
> this a product of hotplug or udev?

Both.  udev can handle network devices just fine, has for years.

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Kay Sievers]

On Thu, Aug 18, 2005 at 01:14:36PM -0700, Greg KH wrote:
> On Thu, Aug 18, 2005 at 12:53:34PM -0700, rich turner wrote:
> > because my linuxrc does not create events or mount /lib/klibc/events in
> > the initrd, then boot.coldplug does not load the network modules.
> 
> That is correct.

If the bootup sequence does not find the directory with the events to
replay, it should fall back to the traditional "coldplug" with scanning
the buses and loading modules. Maybe that's not working in your setup.

> > i realize i can load the network modules in the initrd and everything
> > would be golden, but that is not the purpose of the initrd. in my
> > opinion we already do to much in the initrd because the distributions
> > dont do enough (or do it correctly) in their init scripts. we try to
> > keep the initrd's purpose to do only enough to mount the root
> > filesystem.
> 
> Sorry, but that's not the way we are all moving toward.  With initramfs
> and kinit we are pushing more and more of the early boot stuff into a
> initramfs/initrd image to get it out of the kernel itself.
> 
> > it is important that our process remain generic across all distributions
> > because we need to support many other distributions.
> 
> I wish you the best of luck.  Providing custom kernel images for
> different distros, while ignoring how they do their initrd/initramfs
> boot sequence seems like a futile way to go.  Not to mention breaking
> your customer's service contracts with their distro :)

My best wishes too. All the arch's SUSE supports is strange enough. And
looking at the distro's udev packages gives me the impression, that this
will be a tough road for you. :)

> > does anyone have an opinion as to whether suse's current method will
> > become the standard?
> 
> Is there ever a "standard" for Linux?  :)
> 
> Seriously, I think something like this will become more common as it
> solves a lot of problems people have with early boot processes.  Look at
> how Red Hat solves it (in a different way, but with the same results.)

SUSE's current "event replay from initramfs" works nice so far and is
a generic way to solve the boot sequencing problems. One other option
may be to crawl /sys and submit the events to udevd instead of getting
it from initramfs. That would also work with every kernel, not only
with a special prepared initramfs. We will need to test if this
option works "good enough" - for now it only sounds like a nice
alternative.

> > it appears that udevstart.static creates events but /sbin/udevstart does
> > not. why is that?

There should be no difference. The openSUSE package has only one single
patch to keep the udev rules in the udev daemon instead of parsing the
rules with every event. This patch is available on the hotplug list.

> > is /sbin/hotplugevenrecorder an executable being distributed by suse or
> > is it something that will be coming in the maintained udev?
> 
> http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hš3c3e197c6cf3972c0f9d910ac206aed3df66e7;hbŒ11a2f0ff27264513033691bb818262f009fe4e;f=udeveventrecorder.c
> look like what you are looking for?

We put for now everything SUSE uses in the upstream udev package.
There is no documentation besides our package. If we find a better way
to do it (smarter coldplug), we may replace this.

> > even though we use udevstart in the initrd, is there any real purpose to
> > echoing something (/sbin/udev, /sbin/udevsend, /bin/true) out
> > to /proc/sys/kernel/hotplug while in the initrd?
> 
> Depends on how you want to catch hotplug events.

Yeah, at least /bin/true does not make any sense. :)

> > it is my experience that udev only handles devices that you would expect
> > to find in /dev. how could it have any effect on network interfaces? is
> > this a product of hotplug or udev?
> 
> Both.  udev can handle network devices just fine, has for years.

Yes, udev can rename network interfaces with the same rule logic, it can name
a device node.

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Alexander E. Patrakov]

Kay Sievers wrote:

>SUSE's current "event replay from initramfs" works nice so far and is
>a generic way to solve the boot sequencing problems. One other option
>may be to crawl /sys and submit the events to udevd instead of getting
>it from initramfs. That would also work with every kernel, not only
>with a special prepared initramfs. We will need to test if this
>option works "good enough" - for now it only sounds like a nice
>alternative.
>  
>
Do I understand correctly that the "crawl through sysfs" approach means 
bus-specific conversion between sysfs contents (e.g the fact that 
/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
variables (in this case, PRODUCT=...)? I.e., is it just a 
reimplementation of old /etc/hotplug/*.rc scripts in C?

-- 
Alexander E. Patrakov


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Marco d'Itri]

On Aug 19, "Alexander E. Patrakov" <patrakov@ums.usu.ru> wrote:

> Do I understand correctly that the "crawl through sysfs" approach means 
> bus-specific conversion between sysfs contents (e.g the fact that 
> /sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> variables (in this case, PRODUCT=...)? I.e., is it just a 
> reimplementation of old /etc/hotplug/*.rc scripts in C?
Yes. Actually I am testing this right now in shell (it's not obvious
that they need to be converted in C).

-- 
ciao,
Marco


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Greg KH]

On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
> Kay Sievers wrote:
> 
> >SUSE's current "event replay from initramfs" works nice so far and is
> >a generic way to solve the boot sequencing problems. One other option
> >may be to crawl /sys and submit the events to udevd instead of getting
> >it from initramfs. That would also work with every kernel, not only
> >with a special prepared initramfs. We will need to test if this
> >option works "good enough" - for now it only sounds like a nice
> >alternative.
> > 
> >
> Do I understand correctly that the "crawl through sysfs" approach means 
> bus-specific conversion between sysfs contents (e.g the fact that 
> /sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> variables (in this case, PRODUCT=...)?

Yes, but it's a world easier now that we have added the 'modalias' sysfs
files so we don't have to reconstruct anything.  All we care about at
coldplug time is loading the modules and creating existing device nodes.

The hotplug events can usually be safely ignored.

Although some people don't feel the same way, so they "plug" the hotplug
events and then replay them, which is probably the more correct thing to
do.

> I.e., is it just a reimplementation of old /etc/hotplug/*.rc scripts
> in C?

no.

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Alexander E. Patrakov]

Greg KH wrote:

>On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
>  
>
>>Do I understand correctly that the "crawl through sysfs" approach means 
>>bus-specific conversion between sysfs contents (e.g the fact that 
>>/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
>>variables (in this case, PRODUCT=...)?
>>    
>>
>
>Yes, but it's a world easier now that we have added the 'modalias' sysfs
>files so we don't have to reconstruct anything.  All we care about at
>coldplug time is loading the modules and creating existing device nodes.
>  
>
Sorry, no. We should also care about providing some hook for packages 
like SANE and gPhoto2 to chown/chmod pseudofiles in /proc/bus/usb. This 
requires perfect reconstruction of at least $PRODUCT and $DEVICE.

-- 
Alexander E. Patrakov


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Kay Sievers]

On Fri, Aug 19, 2005 at 10:33:02PM +0600, Alexander E. Patrakov wrote:
> Greg KH wrote:
> 
> >On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
> > 
> >
> >>Do I understand correctly that the "crawl through sysfs" approach means 
> >>bus-specific conversion between sysfs contents (e.g the fact that 
> >>/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> >>variables (in this case, PRODUCT=...)?
> >>   
> >>
> >
> >Yes, but it's a world easier now that we have added the 'modalias' sysfs
> >files so we don't have to reconstruct anything.  All we care about at
> >coldplug time is loading the modules and creating existing device nodes.
> > 
> >
> Sorry, no. We should also care about providing some hook for packages 
> like SANE and gPhoto2 to chown/chmod pseudofiles in /proc/bus/usb. This 
> requires perfect reconstruction of at least $PRODUCT and $DEVICE.

usbfs can go to nowhere. :)
We will get real nodes for libusb access managed by udev with kernel 2.6.14:

  kay@pim:~> tree /sys/class/usb_device/
  /sys/class/usb_device/
  |-- usbdev1.1
  |   |-- dev
  |   `-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb1
  |-- usbdev1.2
  |   |-- dev
  |   `-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb1/1-1
  |-- usbdev2.1
  |   |-- dev
  |   `-- device -> ../../../devices/pci0000:00/0000:00:1d.1/usb2
  |-- usbdev2.2
  |    |-- dev
  |   `-- device -> ../../../devices/pci0000:00/0000:00:1d.1/usb2/2-2
  | -- usbdev3.1
  |   |-- dev
  |   `-- device -> ../../../devices/pci0000:00/0000:00:1d.2/usb3
  |-- usbdev4.1
  |   |-- dev
  |   `-- device -> ../../../devices/pci0000:00/0000:00:1d.7/usb4
  `-- usbdev4.5
      |-- dev
      `-- device -> ../../../devices/pci0000:00/0000:00:1d.7/usb4/4-3

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Marco d'Itri]

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

On Aug 19, Greg KH <greg@kroah.com> wrote:

> Yes, but it's a world easier now that we have added the 'modalias' sysfs
> files so we don't have to reconstruct anything.  All we care about at
> coldplug time is loading the modules and creating existing device nodes.
I'm not sure. You can never know which parameters are used by user space
drivers and similar scripts. So I'm taking the safe route of generating
events which are as similar as possible to the real ones (for most bus
types it's very easy).

-- 
ciao,
Marco

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: general hotplug/udev questions

[Greg KH]

On Fri, Aug 19, 2005 at 10:33:02PM +0600, Alexander E. Patrakov wrote:
> Greg KH wrote:
> 
> >On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
> > 
> >
> >>Do I understand correctly that the "crawl through sysfs" approach means 
> >>bus-specific conversion between sysfs contents (e.g the fact that 
> >>/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> >>variables (in this case, PRODUCT=...)?
> >>   
> >>
> >
> >Yes, but it's a world easier now that we have added the 'modalias' sysfs
> >files so we don't have to reconstruct anything.  All we care about at
> >coldplug time is loading the modules and creating existing device nodes.
> > 
> >
> Sorry, no. We should also care about providing some hook for packages 
> like SANE and gPhoto2 to chown/chmod pseudofiles in /proc/bus/usb. This 
> requires perfect reconstruction of at least $PRODUCT and $DEVICE.

Like Kay said, /proc/bus/usb/???/ is now dead.  We have sane device nodes for
those usbfs files now that udev can manipulate the permissions for
properly.  Run the latest -mm trees to see this.

Kay, you have a libusb patch to support this, right?  Care to share it?

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Kay Sievers]

On Fri, Aug 19, 2005 at 09:47:59AM -0700, Greg KH wrote:
> On Fri, Aug 19, 2005 at 10:33:02PM +0600, Alexander E. Patrakov wrote:
> > Greg KH wrote:
> > 
> > >On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
> > > 
> > >
> > >>Do I understand correctly that the "crawl through sysfs" approach means 
> > >>bus-specific conversion between sysfs contents (e.g the fact that 
> > >>/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> > >>variables (in this case, PRODUCT=...)?
> > >>   
> > >>
> > >
> > >Yes, but it's a world easier now that we have added the 'modalias' sysfs
> > >files so we don't have to reconstruct anything.  All we care about at
> > >coldplug time is loading the modules and creating existing device nodes.
> > > 
> > >
> > Sorry, no. We should also care about providing some hook for packages 
> > like SANE and gPhoto2 to chown/chmod pseudofiles in /proc/bus/usb. This 
> > requires perfect reconstruction of at least $PRODUCT and $DEVICE.
> 
> Like Kay said, /proc/bus/usb/???/ is now dead.  We have sane device nodes for
> those usbfs files now that udev can manipulate the permissions for
> properly.  Run the latest -mm trees to see this.
> 
> Kay, you have a libusb patch to support this, right?  Care to share it?

It requires this crazy udev rule:
  SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"

and this patch to libusb, that falls back to the real nodes if usbfs is
not mounted.

###
Patch against libusb, to prepare for the upcoming changes in
the Linux usb core, which will create real device nodes in /dev
with udev. The following rule:
  SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK="%c"

creates a similar structure in /dev as usbfs creates in /proc to
be picked up by libusb.

I've removed the fallback to /sys/bus/usb cause this is completely
wrong and can and will never work and /dev/usb is used differently
and will also not provide access to the raw usb devices.

Signed-off-by: Kay Sievers <kay.sievers@suse.de>
---

diff -u -r1.73 linux.c
--- linux.c	1 Mar 2005 19:36:42 -0000	1.73
+++ linux.c	9 Aug 2005 00:06:43 -0000
@@ -636,11 +636,8 @@
     if (check_usb_vfs("/proc/bus/usb")) {
       strncpy(usb_path, "/proc/bus/usb", sizeof(usb_path) - 1);
       usb_path[sizeof(usb_path) - 1] = 0;
-    } else if (check_usb_vfs("/sys/bus/usb")) { /* 2.6 Kernel with sysfs */
-      strncpy(usb_path, "/sys/bus/usb", sizeof(usb_path) -1);
-      usb_path[sizeof(usb_path) - 1] = 0;
-    } else if (check_usb_vfs("/dev/usb")) {
-      strncpy(usb_path, "/dev/usb", sizeof(usb_path) - 1);
+    } else if (check_usb_vfs("/dev/bus/usb")) {
+      strncpy(usb_path, "/dev/bus/usb", sizeof(usb_path) -1);
       usb_path[sizeof(usb_path) - 1] = 0;
     } else
       usb_path[0] = 0;	/* No path, no USB support */



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Greg KH]

On Fri, Aug 19, 2005 at 06:56:47PM +0200, Kay Sievers wrote:
> On Fri, Aug 19, 2005 at 09:47:59AM -0700, Greg KH wrote:
> > On Fri, Aug 19, 2005 at 10:33:02PM +0600, Alexander E. Patrakov wrote:
> > > Greg KH wrote:
> > > 
> > > >On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
> > > > 
> > > >
> > > >>Do I understand correctly that the "crawl through sysfs" approach means 
> > > >>bus-specific conversion between sysfs contents (e.g the fact that 
> > > >>/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> > > >>variables (in this case, PRODUCT=...)?
> > > >>   
> > > >>
> > > >
> > > >Yes, but it's a world easier now that we have added the 'modalias' sysfs
> > > >files so we don't have to reconstruct anything.  All we care about at
> > > >coldplug time is loading the modules and creating existing device nodes.
> > > > 
> > > >
> > > Sorry, no. We should also care about providing some hook for packages 
> > > like SANE and gPhoto2 to chown/chmod pseudofiles in /proc/bus/usb. This 
> > > requires perfect reconstruction of at least $PRODUCT and $DEVICE.
> > 
> > Like Kay said, /proc/bus/usb/???/ is now dead.  We have sane device nodes for
> > those usbfs files now that udev can manipulate the permissions for
> > properly.  Run the latest -mm trees to see this.
> > 
> > Kay, you have a libusb patch to support this, right?  Care to share it?
> 
> It requires this crazy udev rule:
>   SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"

Ugh.  Is there any way we can change the kernel name of the class device
to make this easier to handle?  Hm, probably not, unless I get subclass
devices working real soon...

And do we need/want to care about the leading 0's like usbfs had?

> ###
> Patch against libusb, to prepare for the upcoming changes in
> the Linux usb core, which will create real device nodes in /dev
> with udev. The following rule:
>   SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK="%c"
> 
> creates a similar structure in /dev as usbfs creates in /proc to
> be picked up by libusb.
> 
> I've removed the fallback to /sys/bus/usb cause this is completely
> wrong and can and will never work and /dev/usb is used differently
> and will also not provide access to the raw usb devices.
> 
> Signed-off-by: Kay Sievers <kay.sievers@suse.de>
> ---
> 
> diff -u -r1.73 linux.c
> --- linux.c	1 Mar 2005 19:36:42 -0000	1.73
> +++ linux.c	9 Aug 2005 00:06:43 -0000
> @@ -636,11 +636,8 @@
>      if (check_usb_vfs("/proc/bus/usb")) {
>        strncpy(usb_path, "/proc/bus/usb", sizeof(usb_path) - 1);
>        usb_path[sizeof(usb_path) - 1] = 0;
> -    } else if (check_usb_vfs("/sys/bus/usb")) { /* 2.6 Kernel with sysfs */
> -      strncpy(usb_path, "/sys/bus/usb", sizeof(usb_path) -1);
> -      usb_path[sizeof(usb_path) - 1] = 0;
> -    } else if (check_usb_vfs("/dev/usb")) {
> -      strncpy(usb_path, "/dev/usb", sizeof(usb_path) - 1);
> +    } else if (check_usb_vfs("/dev/bus/usb")) {
> +      strncpy(usb_path, "/dev/bus/usb", sizeof(usb_path) -1);
>        usb_path[sizeof(usb_path) - 1] = 0;
>      } else
>        usb_path[0] = 0;	/* No path, no USB support */


Hm, why was libusb checking for sysfs stuff in the first place?  It
couldn't do anything with those files, right?

thanks,

greg k-h


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Kay Sievers]

On Fri, Aug 19, 2005 at 10:11:16AM -0700, Greg KH wrote:
> On Fri, Aug 19, 2005 at 06:56:47PM +0200, Kay Sievers wrote:
> > On Fri, Aug 19, 2005 at 09:47:59AM -0700, Greg KH wrote:
> > > On Fri, Aug 19, 2005 at 10:33:02PM +0600, Alexander E. Patrakov wrote:
> > > > Greg KH wrote:
> > > > 
> > > > >On Fri, Aug 19, 2005 at 03:09:59PM +0600, Alexander E. Patrakov wrote:
> > > > > 
> > > > >
> > > > >>Do I understand correctly that the "crawl through sysfs" approach means 
> > > > >>bus-specific conversion between sysfs contents (e.g the fact that 
> > > > >>/sys/bus/usb/devices/1-1/idProduct contains "4002" here) and environment 
> > > > >>variables (in this case, PRODUCT=...)?
> > > > >>   
> > > > >>
> > > > >
> > > > >Yes, but it's a world easier now that we have added the 'modalias' sysfs
> > > > >files so we don't have to reconstruct anything.  All we care about at
> > > > >coldplug time is loading the modules and creating existing device nodes.
> > > > > 
> > > > >
> > > > Sorry, no. We should also care about providing some hook for packages 
> > > > like SANE and gPhoto2 to chown/chmod pseudofiles in /proc/bus/usb. This 
> > > > requires perfect reconstruction of at least $PRODUCT and $DEVICE.
> > > 
> > > Like Kay said, /proc/bus/usb/???/ is now dead.  We have sane device nodes for
> > > those usbfs files now that udev can manipulate the permissions for
> > > properly.  Run the latest -mm trees to see this.
> > > 
> > > Kay, you have a libusb patch to support this, right?  Care to share it?
> > 
> > It requires this crazy udev rule:
> >   SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"
> 
> Ugh.  Is there any way we can change the kernel name of the class device
> to make this easier to handle?  Hm, probably not, unless I get subclass
> devices working real soon...

Not that I know. We could add regex support to udev to solve that
in-process. :)

> And do we need/want to care about the leading 0's like usbfs had?

Works fine without, but adding it with the shell should be easy, just
makes the rule a bit longer. :)

> > ###
> > Patch against libusb, to prepare for the upcoming changes in
> > the Linux usb core, which will create real device nodes in /dev
> > with udev. The following rule:
> >   SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK="%c"
> > 
> > creates a similar structure in /dev as usbfs creates in /proc to
> > be picked up by libusb.
> > 
> > I've removed the fallback to /sys/bus/usb cause this is completely
> > wrong and can and will never work and /dev/usb is used differently
> > and will also not provide access to the raw usb devices.
> > 
> > Signed-off-by: Kay Sievers <kay.sievers@suse.de>
> > ---
> > 
> > diff -u -r1.73 linux.c
> > --- linux.c	1 Mar 2005 19:36:42 -0000	1.73
> > +++ linux.c	9 Aug 2005 00:06:43 -0000
> > @@ -636,11 +636,8 @@
> >      if (check_usb_vfs("/proc/bus/usb")) {
> >        strncpy(usb_path, "/proc/bus/usb", sizeof(usb_path) - 1);
> >        usb_path[sizeof(usb_path) - 1] = 0;
> > -    } else if (check_usb_vfs("/sys/bus/usb")) { /* 2.6 Kernel with sysfs */
> > -      strncpy(usb_path, "/sys/bus/usb", sizeof(usb_path) -1);
> > -      usb_path[sizeof(usb_path) - 1] = 0;
> > -    } else if (check_usb_vfs("/dev/usb")) {
> > -      strncpy(usb_path, "/dev/usb", sizeof(usb_path) - 1);
> > +    } else if (check_usb_vfs("/dev/bus/usb")) {
> > +      strncpy(usb_path, "/dev/bus/usb", sizeof(usb_path) -1);
> >        usb_path[sizeof(usb_path) - 1] = 0;
> >      } else
> >        usb_path[0] = 0;	/* No path, no USB support */
> 
> 
> Hm, why was libusb checking for sysfs stuff in the first place?  It
> couldn't do anything with those files, right?

No, it doesn't make sense. Seems someone was a bit confused about sysfs
and thought /proc/bus will move to /sys/bus :)

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Alexander E. Patrakov]

Kay Sievers wrote:

>On Fri, Aug 19, 2005 at 09:47:59AM -0700, Greg KH wrote:
>  
>
>>Like Kay said, /proc/bus/usb/???/ is now dead.  We have sane device nodes for
>>those usbfs files now that udev can manipulate the permissions for
>>properly.  Run the latest -mm trees to see this.
>>
>>Kay, you have a libusb patch to support this, right?  Care to share it?
>>    
>>
>
>It requires this crazy udev rule:
>  SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"
>
>and this patch to libusb, that falls back to the real nodes if usbfs is
>not mounted.
>  
>
<snip patch>

With this patch, I was able to scan some images without mounting usbfs 
(linux-2.6.13-rc6-mm1). Thanks!

-- 
Alexander E. Patrakov


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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: general hotplug/udev questions

[Kay Sievers]

On Sun, Aug 21, 2005 at 01:16:44PM +0600, Alexander E. Patrakov wrote:
> Kay Sievers wrote:
> >On Fri, Aug 19, 2005 at 09:47:59AM -0700, Greg KH wrote:
> >
> >>Like Kay said, /proc/bus/usb/???/ is now dead.  We have sane device nodes 
> >>for
> >>those usbfs files now that udev can manipulate the permissions for
> >>properly.  Run the latest -mm trees to see this.
> >>
> >>Kay, you have a libusb patch to support this, right?  Care to share it?
> >>   
> >
> >It requires this crazy udev rule:
> > SUBSYSTEM="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev} 
> > B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", SYMLINK+="%c"
> >
> >and this patch to libusb, that falls back to the real nodes if usbfs is
> >not mounted.

> With this patch, I was able to scan some images without mounting usbfs 
> (linux-2.6.13-rc6-mm1). Thanks!

Nice! Many thanks for testing it.

Kay


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
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