headers
Kay Sievers | 1 Mar 2009 16:49

Re: Regression in udev-139?

On Sat, Feb 28, 2009 at 10:15, Chris Clayton <chris2553 <at> googlemail.com> wrote:
> I have a script that is run via udev whenever a usb storage device is plugged in
> to my computer - all it does is place an icon on the desktop. A similar script
> hides the icon again when the device is unplugged. OK, it's not sophisticated,
> but it does the job.
>
> I've been using the scripts for maybe two years or so without problem, but
> yesterday I built and installed udev-139 and they stopped working.

That still works fine here:
  udevadm monitor --env --udev | grep ID_BUS
  ID_BUS=usb
  ID_BUS=usb
  ID_BUS=usb
  ID_BUS=usb

It's likely something wrong with your rules, maybe left-over stuff in
/etc/rules.d/, while the default udev rules are now in
/lib/udev/rules.d/.

You can check what's going on, with:
  udevadm test /class/block/sdb
an you look for:
  util_run_program: 'usb_id --export /devices/ ... /block/sdb'
  ...
  util_run_program: '/lib/udev/usb_id' (stdout) 'ID_BUS=usb'
  ...

Kay
--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ozan Çağlayan | 2 Mar 2009 22:09
Picon
Favicon

Interaction of udev with the init subsystem

Hi,

I'm maintaining the udev package for Pardus, a GNU/Linux distribution
mainly developed in Turkey.

After doing some investigations of the startup time on our distribution,
I've figured that udev related invocations takes a lot of time.

1) The startup of the daemon is quick enough, no problem here,
2) The first trigger+settle takes ~4.5 seconds to complete.

We're currently using udev-126 but I also tried 137, and the performance
is quite the same.

I wonder what are the points that a distribution packager/maintainer should consider
when starting/stopping udev for having the best startup time.

My second question is about the orphaned rule files left in /dev/.udev
after triggering the event processing on a read-only root filesystem. I'm succesfully
collecting those rules, moving them into /etc/udev/rules.d and recalling trigger
after mounting the root filesystem read-write. If I don't retrigger,
no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains
a media during boot. Retriggering here takes ~0.11 seconds.

It would be very nice to have a detailed documentation for udev beside rule writing stuff.

Thanks,

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg KH | 2 Mar 2009 22:32
Gravatar

Re: Interaction of udev with the init subsystem

On Mon, Mar 02, 2009 at 11:09:39PM +0200, Ozan Çağlayan wrote:
> Hi,
> 
> I'm maintaining the udev package for Pardus, a GNU/Linux distribution
> mainly developed in Turkey.
> 
> After doing some investigations of the startup time on our distribution,
> I've figured that udev related invocations takes a lot of time.
> 
> 1) The startup of the daemon is quick enough, no problem here,
> 2) The first trigger+settle takes ~4.5 seconds to complete.
> 
> We're currently using udev-126 but I also tried 137, and the performance
> is quite the same.

It's the modprobe stuff that is taking most of the time, right?  That's
not udev.

> I wonder what are the points that a distribution packager/maintainer should consider
> when starting/stopping udev for having the best startup time.
> 
> My second question is about the orphaned rule files left in /dev/.udev
> after triggering the event processing on a read-only root filesystem. I'm succesfully
> collecting those rules, moving them into /etc/udev/rules.d and recalling trigger
> after mounting the root filesystem read-write. If I don't retrigger,
> no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains
> a media during boot. Retriggering here takes ~0.11 seconds.
> 
> It would be very nice to have a detailed documentation for udev beside rule writing stuff.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kay Sievers | 3 Mar 2009 00:36

Re: Interaction of udev with the init subsystem

On Mon, Mar 2, 2009 at 22:09, Ozan Çağlayan <ozan <at> pardus.org.tr> wrote:
> I'm maintaining the udev package for Pardus, a GNU/Linux distribution
> mainly developed in Turkey.
>
> After doing some investigations of the startup time on our distribution,
> I've figured that udev related invocations takes a lot of time.
>
> 1) The startup of the daemon is quick enough, no problem here,
> 2) The first trigger+settle takes ~4.5 seconds to complete.

Run "udevadm monitor" during that time, and check which of the events
is blocking the "settle" for that long.

> My second question is about the orphaned rule files left in /dev/.udev
> after triggering the event processing on a read-only root filesystem. I'm succesfully
> collecting those rules, moving them into /etc/udev/rules.d and recalling trigger
> after mounting the root filesystem read-write. If I don't retrigger,
> no dvd, cdrw, etc. symlink are created in /dev if the optical drive contains
> a media during boot. Retriggering here takes ~0.11 seconds.
>
> It would be very nice to have a detailed documentation for udev beside rule writing stuff.

I don't think there is much more you need to do, than you do already.

It very much depends on the specific distro setup, like some mount the
rootfs rw, so there are no rules to move around, and a single coldplug
run does all needed work.
Some systems support things like /usr on a different disk, which has
its very own set of problems, which will likely get harder over time
to support, because we got more and more udev consumers which rely on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Prokop | 3 Mar 2009 16:50
Favicon

[PATCH] Fix compile error in debug mode: error: ‘struct <anonymous>’ has no member named ‘i’

When building with './configure --enable-debug && make' it fails with:

  udev-rules.c: In function ‘dump_token’:
  udev-rules.c:366: error: ‘struct <anonymous>’ has no member named ‘i’

Signed-off-by: Michael Prokop <mika <at> grml.org>

diff --git a/udev/udev-rules.c b/udev/udev-rules.c
index 905a1a0..663a6d4 100644
--- a/udev/udev-rules.c
+++ b/udev/udev-rules.c
 <at>  <at>  -363,7 +363,7  <at>  <at>  static void dump_token(struct udev_rules *rules, struct token *token)
 		    token_str(type), operation_str(op), value, string_glob_str(glob), token->key.mode);
 		break;
 	case TK_A_INOTIFY_WATCH:
-		dbg(rules->udev, "%s %u\n", token_str(type), token->key.i);
+		dbg(rules->udev, "%s %u\n", token_str(type), token->key.watch);
 		break;
 	case TK_A_NUM_FAKE_PART:
 		dbg(rules->udev, "%s %u\n", token_str(type), token->key.num_fake_part);
--

-- 
1.5.6.5

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Kay Sievers | 3 Mar 2009 17:40

Re: [PATCH] Fix compile error in debug mode: error: ‘struct <anonymous>’ has no member named ‘i’

On Tue, Mar 3, 2009 at 16:50, Michael Prokop <mika <at> grml.org> wrote:
> When building with './configure --enable-debug && make' it fails with:
>
>  udev-rules.c: In function ‘dump_token’:
>  udev-rules.c:366: error: ‘struct <anonymous>’ has no member named ‘i’

Applied.

Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Bobby Whitfield | 4 Mar 2009 09:54

Augment your lovestick and increase your confidence

Make your fantasies come true tonight. http://xtixu.moverhappy.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Rob Desbois | 5 Mar 2009 10:41
Picon
Favicon

linux hotplug SF website

Hi,

Apologies for putting this on the list -- I did try the linux-hotplug-devel list but doesn't seem to be any
activity there.

The website http://linux-hotplug.sourceforge.net/ looks great but isn't working; the internal links
on the LHS which point to /?selected=foo don't go anywhere but remain on the front page.

Any suggestions? I was looking for a good guide to the user mode s/w and subsystems.

TIA,
--rob

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Leandro Dorileo | 5 Mar 2009 20:18
Picon
Gravatar

Re: linux hotplug SF website

Hi Rob

On Thu, Mar 5, 2009 at 5:41 AM, Rob Desbois <rob.desbois <at> chronos.co.uk> wrote:
> Hi,
>
> Apologies for putting this on the list -- I did try the linux-hotplug-devel list but doesn't seem to be any
activity there.

yes, linux-hotplug-devel mailing list is not been used any more, it
was moved to vger since august 2007[1].

>
> The website http://linux-hotplug.sourceforge.net/ looks great but isn't working; the internal links
on the LHS which point to /?selected=foo don't go anywhere but remain on the front page.

I guess it`s not been maintained just like the mailing list.

> Any suggestions? I was looking for a good guide to the user mode s/w and subsystems.

If you want docs about "Writing udev rules" you can find it in the
source code /doc folder or(as pointed by the file in that folder) on
the web[2].

Lwn has published some articles about udev design and motivation, you
may find something useful.

Hope I have helped.

[1] - http://marc.info/?l=linux-hotplug&m=119554189818396&w=2
[2] - http://www.reactivated.net/writing_udev_rules.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald Hoyer | 6 Mar 2009 11:29
Picon
Favicon
Gravatar

libvolume_id minor number not increased

Kay,

because you added the symbol volume_id_set_uuid_sub() in commit 14e18278, you 
have to increase the library minor version!

For the libtool versions scheme this means:

dnl Increment CURRENT if any interfaces have been added, removed,
dnl or changed since the last update and set REVISION to 0.
dnl
dnl Increment REVISION every time the code changes
dnl
dnl If any interfaces have been added since the last public release,
dnl then increment AGE.
dnl If any interfaces have been removed since the last public release,
dnl then set AGE to 0.

$ git diff configure.ac
diff --git a/configure.ac b/configure.ac
index 7fbc42c..f32b39f 100644
--- a/configure.ac
+++ b/configure.ac
 <at>  <at>  -22,9 +22,9  <at>  <at>  AC_SUBST(LIBUDEV_LT_REVISION)
  AC_SUBST(LIBUDEV_LT_AGE)

  dnl /* libvolume_id version */
-VOLID_LT_CURRENT=1
-VOLID_LT_REVISION=9
-VOLID_LT_AGE=0
+VOLID_LT_CURRENT=2
(Continue reading)

Permalink | Reply | 1 comment |

Gmane