headers
Krosh Ivanov | 4 Apr 2011 16:04
Picon

socket and udev

I want to use udev to detect a storage usb disk when it is plugged.
Since the version of udev here is v120, it is need to use sockets to
receive messages with data about events, such as it is used in
udevmonitor.c. However, bind function returns an error message ("bind
failed: Address already in use") because it is used bind again in
another process (udevd uses it first). Is there another way to get the
events from udev?

Thanks,
Ivan
--
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
Dan Nicholson | 4 Apr 2011 18:13
Picon

Re: socket and udev

On Mon, Apr 4, 2011 at 7:04 AM, Krosh Ivanov <krosh.ivan <at> gmail.com> wrote:
> I want to use udev to detect a storage usb disk when it is plugged.
> Since the version of udev here is v120, it is need to use sockets to
> receive messages with data about events, such as it is used in
> udevmonitor.c. However, bind function returns an error message ("bind
> failed: Address already in use") because it is used bind again in
> another process (udevd uses it first). Is there another way to get the
> events from udev?

libudev?

http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/

I guess it's probably not available on that old udev. You could use
libhal on that system, or you could add a rule to create an AF_LOCAL
socket like was done for hal and udevmonitor:

RUN+="socket: <at> /your/name/here"

--
Dan
--
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
Nao Nishijima | 5 Apr 2011 14:49
Picon

[PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel.

This patch series provides a SCSI option for persistent device
names in kernel. With this option, user can always assign a
same device name (e.g. sda) to a specific device according to
udev rules and device id.

Issue:
Recently, kernel registers block devices in parallel. As a result,
different device names will be assigned at each boot time. This
will confuse file-system mounter, thus we usually use persistent
symbolic links provided by udev. However, dmesg and procfs outputs
show device names instead of the symbolic link names. This causes
a serious problem when managing multiple devices (e.g. on a
large-scale storage), because usually, device errors are output
with device names on dmesg. We also concern about some commands
which output device names, as well as kernel messages.

Solution:
To assign a persistent device name, I create unnamed devices (not
a block device, but an intermediate device. users cannot read/write
this device). When scsi device driver finds a LU, the LU is registered
as an unnamed device and inform to udev. After udev finds the unnamed
device, udev assigns a persistent device name to a specific device
according to udev rules and registers it as a block device. Hence,
this is just a naming, not a renaming.

Some users are satisfied with current udev solution. Therefore, my
proposal is implemented as an option.

If using this option, add the following kernel parameter.
(Continue reading)

Permalink | Reply | 18 comments |
headers
Karel Zak | 5 Apr 2011 15:30
Picon
Favicon
Gravatar

Re: [ANNOUNCE] udev 167 release

On Thu, Mar 31, 2011 at 12:08:40PM +0200, Kay Sievers wrote:
> On Thu, Mar 31, 2011 at 10:03, Gabor Z. Papp <gzp <at> papp.hu> wrote:
> > * Kay Sievers <kay.sievers <at> vrfy.org>:
> >
> > | Here comes a new udev version. Thanks to all who have contributed to
> > | this release.
> >
> > $ dmesg
> > <30>udev[1589]: converting old udev database
> > <30>udev[1590]: starting version 167
> >
> > what is/mean <30> before udev[1589]?

I'm not able reproduce this problem on Fedora-15.

After update to udev-167:

        # dmesg -r | grep udev
        <6>[    2.061910] udev[92]: starting version 166
        <6>[   10.884330] udev[362]: starting version 166
        <30>[ 3154.877757] udev[1780]: converting old udev database
        <30>[ 3154.975428] udev[1780]: starting version 167

'-r' means raw, so <30> prefix is there. Normal dmesg:

        # dmesg | grep udev
        [    2.061910] udev[92]: starting version 166
        [   10.884330] udev[362]: starting version 166
        [ 3154.877757] udev[1780]: converting old udev database
        [ 3154.975428] udev[1780]: starting version 167
(Continue reading)

Permalink | Reply | 2 comments |
headers
Maik Hänig | 5 Apr 2011 17:08
Picon

libudev compiling

Hi,

if I extract the udev sources how can I compile the libudev?

Is there any file where it is described. I want to cross compile the 
libudev for arm.

best regards
--
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
Greg KH | 5 Apr 2011 18:14
Gravatar

Re: [PATCH 1/2] SCSI: Add a SCSI option for persistent device names in Kernel.

On Tue, Apr 05, 2011 at 09:49:46PM +0900, Nao Nishijima wrote:
> This patch series provides a SCSI option for persistent device
> names in kernel. With this option, user can always assign a
> same device name (e.g. sda) to a specific device according to
> udev rules and device id.
> 
> Issue:
> Recently, kernel registers block devices in parallel. As a result,
> different device names will be assigned at each boot time. This
> will confuse file-system mounter, thus we usually use persistent
> symbolic links provided by udev.

Yes, that is what you should use if you care about this.

> However, dmesg and procfs outputs
> show device names instead of the symbolic link names. This causes
> a serious problem when managing multiple devices (e.g. on a
> large-scale storage), because usually, device errors are output
> with device names on dmesg.

Then fix your tools that read the output of these files to point to the
proper persistent name instead of trying to get the kernel to solve the
problem.

> We also concern about some commands
> which output device names, as well as kernel messages.

What commands are you concerned about?

> Solution:
(Continue reading)

Permalink | Reply | 11 comments |
headers
Seth Forshee | 5 Apr 2011 18:42
Favicon

[PATCH] keymap: Support Dell Latitude XT2 tablet-mode navigation keys

Hi Martin,

The patch that follows gets some tablet-mode keys working on the
Latitude XT2. The scan codes for these keys are apparently used for
different functions on some other models, so I added a new keymap file
for the XT2 to handle the overlap. There's a good chance that what I've
done is suboptimal -- I mean that either these keys apply to some other
models, or that some of the keys in the current dell keymap should be
moved over to the new file, or both. I just don't have enough
information to know which keys are used on which models. If that
information is available somewhere I'd be happy to rearrange the
keymaps, but for now I opted for the conservative approach that won't
change how things currently work for other Dell models.

Thanks,
Seth

Seth Forshee (1):
  keymap: Support Dell Latitude XT2 tablet-mode navigation keys

 Makefile.am                             |    1 +
 extras/keymap/95-keymap.rules           |    1 +
 extras/keymap/keymaps/dell-latitude-xt2 |    4 ++++
 3 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 extras/keymap/keymaps/dell-latitude-xt2

--
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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Seth Forshee | 5 Apr 2011 18:43
Favicon

[PATCH] keymap: Support Dell Latitude XT2 tablet-mode navigation keys

The XT2 has a rocker (up/down/enter) and back button on the side
in tablet mode, none of which work currently. Add entries for
these keys.

There is some overlap here with scan codes used in other Dell
models, so these buttons are put in a new file specific to this
model.

Signed-off-by: Seth Forshee <seth.forshee <at> canonical.com>
---
 Makefile.am                             |    1 +
 extras/keymap/95-keymap.rules           |    1 +
 extras/keymap/keymaps/dell-latitude-xt2 |    4 ++++
 3 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 extras/keymap/keymaps/dell-latitude-xt2

diff --git a/Makefile.am b/Makefile.am
index 2c20f46..4244089 100644
--- a/Makefile.am
+++ b/Makefile.am
 <at>  <at>  -568,6 +568,7  <at>  <at>  dist_udevkeymap_DATA = \
 	extras/keymap/keymaps/asus \
 	extras/keymap/keymaps/compaq-e_evo \
 	extras/keymap/keymaps/dell \
+	extras/keymap/keymaps/dell-latitude-xt2 \
 	extras/keymap/keymaps/everex-xt5000 \
 	extras/keymap/keymaps/fujitsu-amilo_pa_2548 \
 	extras/keymap/keymaps/fujitsu-amilo_pro_edition_v3505 \
diff --git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 44d5064..350f111 100644
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Pitt | 5 Apr 2011 19:40
Favicon
Gravatar

Re: [PATCH] keymap: Support Dell Latitude XT2 tablet-mode navigation keys

Hello Seth,

Seth Forshee [2011-04-05 11:42 -0500]:
> I just don't have enough information to know which keys are used on
> which models. If that information is available somewhere I'd be
> happy to rearrange the keymaps, but for now I opted for the
> conservative approach that won't change how things currently work
> for other Dell models.

I don't know either I'm afraid, so let's keep the model specific
version for now. Pushed to git, thanks!

Martin
--

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
--
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
Gabor Z. Papp | 5 Apr 2011 20:45
Picon

Re: [ANNOUNCE] udev 167 release

* Karel Zak <kzak <at> redhat.com>:

| > > what is/mean <30> before udev[1589]?

| I'm not able reproduce this problem on Fedora-15.

$ dmesg -r | grep udev
<4><30>udev[1144]: starting version 167

In this case my syslog-ng 2.1.4 is the ancient/too old?

Thanks and sorry for the noise.
--
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 |

Gmane