headers
Greg KH | 1 Apr 2006 03:05
Gravatar

Re: How to check if driver is in-built or module?

On Fri, Mar 31, 2006 at 11:52:25PM +0300, juuso.alasuutari <at> tamperelainen.org wrote:
> Returning again to the module autoloading issue.
> 
> First of all, thank you very much for the help! :) I've managed to exile hotplug
> from my system.
> 
> I still have a question, though: Does autoloading modules & firmware with udev
> also work with kernels older than 2.6.15?

Yes, it should.

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Moshe Yudkowsky | 2 Apr 2006 15:41

Why not picking up ENV variables?

Here's the output of udevmonitor --env:

UDEV  [1143983665.856252] add <at> /block/sdb
UDEV_LOG=3
ACTION=add
DEVPATH=/block/sdb
SUBSYSTEM=block
SEQNUM=2389
MINOR=16
MAJOR=8
PHYSDEVPATH=/devices/pci0000:00/0000:00:10.3/usb4/4-4/4-4:1.0/host6/target6:0:0/6:0:0:0
PHYSDEVBUS=scsi
PHYSDEVDRIVER=sd
UDEVD_EVENT=1
ID_VENDOR=iriver
ID_MODEL=MassStorage_Disc
ID_REVISION=0001
ID_SERIAL=iriver_MassStorage_Disc
ID_TYPE=disk
ID_BUS=usb
ID_PATH=pci-0000:00:10.3-usb-0:4:1.0-scsi-0:0:0:0
DEVNAME=/dev/scsi/host6/bus0/target0/lun0/disc
DEVLINKS=/dev/sdb /dev/discs/disc2/disc 
/dev/disk/by-id/usb-iriver_MassStorage_Disc 
/dev/disk/by-path/pci-0000:00:10.3-usb-0:4:1.0-scsi-0:0:0:0

Now, I will tell you the truth: I have not yet been able to find any 
documentation that states, explicitly, what variables are part of SYSFS 
and what variables are part of ENV. I can figure out -- only by running 
udevinfo and reading the "sysfs" prefixes -- what info is SYSFS only.
(Continue reading)

Permalink | Reply | 6 comments |
headers
John Que | 2 Apr 2006 16:04
Picon

Re: Hotplug and udev - a question

Hello,

Thanks for the link!
I read it carefully; all of it , except of the last 2
paragraphs, deal mainly with hotplug and improvements that
were made in hotplug-ng.

Now, to the last 2 paragrapghs:

>With the release of the 050 release of udev, if /sbin/udevsend is the kernel
>hotplug program (it can be changed by modifying the value of the
>/proc/sys/kernel/hotplug file), then it operates like the original
>/etc/hotplug.d multiplexer program as well as handling all of the udev device
>node generation. This ensures that the /etc/hotplug.d/ invocations
happen in the
>proper order, and in sequence for the same device. Gentoo Linux
already supports
>this mode of operation.

>However, not every user wants to use udev. Because of that, the hotplug-ng
>project is continuing, even if it seems like they are competing against each
>other in implementing the same functionality. As the same developers are doing
>the work in both programs, all users of Linux benefit with a faster module
>loading process, and further advancements in hotplug functionality.

What I don't get from here is what is exactly the advantage
of using udev solely over using udev with hotplug and what
is the exact reason that hotplug is deprecated.
Is it because there is some functionality which is duplicated
in udev and in hotplug ? or some other reason ?
(Continue reading)

Permalink | Reply | 15 comments |
headers
Robert Kennedy | 2 Apr 2006 16:57
Picon
Favicon

How to Debug udev?

I just upgraded my arch system from udev 86 to udev 088.  Now my system 
hangs at the "Loading Udev Events" stage of the bootup.  (I had no problems 
with the previous version of udev)

Is there a way I can debug what is going on?

Rob

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Moshe Yudkowsky | 2 Apr 2006 16:58

Re: Why not picking up ENV variables?

In another test, I've modified the rules:

SUBSYSTEM=="block" IMPORT{program}="path_id $devpath"

SUBSYSTEM=="block", ACTION=="add", ENV{ID_VENDOR}=="iriver", 
ENV{ID_SERIAL}=="iriver_MassStorage_Disc", SYMLINK+="iriver", 
RUN+="/etc/hotplug/usb/iriver", ENV{REMOVE_CMD}="/etc/hotplug/usb/iriver 
remove"

SUBSYSTEM=="block", ACTION=="remove",  ENV{ID_VENDOR}=="iriver", 
ENV{ID_SERIAL}=="iriver_MassStorage_Disc", RUN+="/etc/hotplug/usb/iriver 
remove"

and I've also set them to run *after* the persistent.rules file. This 
should make certain that ID_VENDOR and ID_PATH are in the ENV -- even 
though I've certainly seen them in udevinfo printouts even without 
adding path_id myself.

While "add" works, the "remove" does not work. Furthermore, even thought 
run.rules executes, the ENV{REMOVE_CMD} that I've set does not run.

Help?

--

-- 
  Moshe Yudkowsky
  work: http://www.Disaggregate.com
  book: http://www.PebbleAndAvalanche.com

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
(Continue reading)

Permalink | Reply | 5 comments |
headers
Andrey Borzenkov | 2 Apr 2006 18:47
Picon

Re: Why not picking up ENV variables?


On Sunday 02 April 2006 18:58, Moshe Yudkowsky wrote:
> In another test, I've modified the rules:
>
> SUBSYSTEM=="block" IMPORT{program}="path_id $devpath"
>
> SUBSYSTEM=="block", ACTION=="add", ENV{ID_VENDOR}=="iriver",
> ENV{ID_SERIAL}=="iriver_MassStorage_Disc", SYMLINK+="iriver",
> RUN+="/etc/hotplug/usb/iriver", ENV{REMOVE_CMD}="/etc/hotplug/usb/iriver
> remove"
>
> SUBSYSTEM=="block", ACTION=="remove",  ENV{ID_VENDOR}=="iriver",
> ENV{ID_SERIAL}=="iriver_MassStorage_Disc", RUN+="/etc/hotplug/usb/iriver
> remove"
>
> and I've also set them to run *after* the persistent.rules file. This
> should make certain that ID_VENDOR and ID_PATH are in the ENV -- even
> though I've certainly seen them in udevinfo printouts even without
> adding path_id myself.
>
> While "add" works, the "remove" does not work.

Unless I misread the code, stored environment is not available when matching 
device event; it is imported after that, immediately before RUN programs are 
going to be run. As most other callouts are run only on ACTION=="add", it 
means environment is mostly not available for remove rules.

> Furthermore, even thought 
> run.rules executes, the ENV{REMOVE_CMD} that I've set does not run.
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Moshe Yudkowsky | 2 Apr 2006 21:48
Picon
Favicon

Re: Why not picking up ENV variables?

> Unless I misread the code, stored environment is not available when matching 
> device event; it is imported after that, immediately before RUN programs are 
> going to be run. As most other callouts are run only on ACTION=="add", it 
> means environment is mostly not available for remove rules.

I will certainly try to find time to run against this patch. Is there a 
"best practices" method for "remove" events? If sysfs isn't available, 
and I can't import to the environment via path_id, then what's left to 
match against?

--

-- 
Moshe Yudkowsky * moshe <at> pobox.com * www.pobox.com/~moshe
  "The odds are good, but the goods are odd."
    	     -- Alaskan women, on the high ratio of men to women in Alaska

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Chris Smith | 2 Apr 2006 22:21
Picon

Re: Hotplug and udev - a question

>>>>> "John" == John Que <qwejohn <at> gmail.com> writes:
    John> What I don't get from here is what is exactly the advantage
    John> of using udev solely over using udev with hotplug and what
    John> is the exact reason that hotplug is deprecated.  Is it
    John> because there is some functionality which is duplicated in
    John> udev and in hotplug ? or some other reason ?

Take this with a grain of salt, but my understanding is that, from a
kernel perspective, the udev way is smaller, simpler, and more
flexible.
Best,
Chris

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Permalink | Reply | 0 comments |
headers
Greg KH | 2 Apr 2006 22:24
Gravatar

Re: Hotplug and udev - a question

On Sun, Apr 02, 2006 at 05:04:30PM +0300, John Que wrote:
> Hello,
> 
> Thanks for the link!
> I read it carefully; all of it , except of the last 2
> paragraphs, deal mainly with hotplug and improvements that
> were made in hotplug-ng.
> 
> Now, to the last 2 paragrapghs:
> 
> >With the release of the 050 release of udev, if /sbin/udevsend is the kernel
> >hotplug program (it can be changed by modifying the value of the
> >/proc/sys/kernel/hotplug file), then it operates like the original
> >/etc/hotplug.d multiplexer program as well as handling all of the udev device
> >node generation. This ensures that the /etc/hotplug.d/ invocations
> happen in the
> >proper order, and in sequence for the same device. Gentoo Linux
> already supports
> >this mode of operation.
> 
> >However, not every user wants to use udev. Because of that, the hotplug-ng
> >project is continuing, even if it seems like they are competing against each
> >other in implementing the same functionality. As the same developers are doing
> >the work in both programs, all users of Linux benefit with a faster module
> >loading process, and further advancements in hotplug functionality.
> 
> 
> What I don't get from here is what is exactly the advantage
> of using udev solely over using udev with hotplug and what
> is the exact reason that hotplug is deprecated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joachim Breitner | 2 Apr 2006 22:58
Picon
Favicon
Gravatar

Re: cm4000 device creation again

Hi linux-hotplug list,

I did not get a reply on the following diagnostics. The bug is either
still in the stable 2.6.16 release, or it is not a kernel bug at all, in
which case I'd like to hear pointers where to continue looking.

BTW, after creating the device node by hand, everything seems to work
fine.

Thanks,
Joachim

Am Montag, den 13.03.2006, 22:33 +0100 schrieb Joachim Breitner:
> Am Montag, den 13.03.2006, 08:02 +0100 schrieb Kay Sievers:
> > What does:
> >   cat /sys/class/cardman_4000/cmm0/dev
> > print?
> I only have
> # ls /sys/class/cardman_4000/cmm0/
> uevent
> 
> > Does:
> >   udevmonitor --env
> > show:
> >   ...
> >   MAJOR=
> >   MINOR=
> >   ...
> > if you trigger the device event with:
> >   echo add > /sys/class/cardman_4000/cmm0/uevent
(Continue reading)

Permalink | Reply | 0 comments |

Gmane