the file system for /dev

All,

The setup section of the udev README mentions that /dev should get the
devtmpfs file system, but it also says that udev can be run on a blank
tmpfs as long as you create /dev/{null,kmsg,console}. Also, the
requirements section never mentions CONFIG_DEVTMPFS.

So, I guess I'm attempting to figure out what is preferred. Is devtmpfs
preferred for distros? What are reasons that someone might not want to
use devtmpfs with udev?

William

[ANNOUNCE] udev 173

Here comes a new udev version. Thanks to all who have contributed to
this release.

The tarball can be found here:
 ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/

The development repository can be found here:
 http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary

The ChangeLog can be found here:
 http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog

udev 173
========
Bugfixes.

The udev-acl extra is no longer enabled by default. To enable it,
--enable-udev_acl needs to be given at ./configure time. On systemd
systems, the udev-acl rules prevent it from running as the functionality
has moved to systemd.

udev 172
========
Bugfixes.

Udev now enables kernel media-presence polling if available. Part
of udisks optical drive tray-handling moved to cdrom_id: The tray
is locked as soon as a media is detected to enable the receiving
of media-eject-request events. Media-eject-request events will
eject the media.

separate /usr/broken with udev extras

All,

Wehave the following bug report on gentoo linux regarding udev and and
external dependencies on a system with a separate /usr partition.

http://bugs.gentoo.org/show_bug.cgi?id=364235

Comment #1, in particular, is of interest to me, because I think we
could solve this on gentoo if we had event types that told us when these
failures happened. Right now, it seems that all ofthese failures are
marked nomatch by udev, could they be marked as failed instead?

Thanks,

William

failures occurred or 
--
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

udev_monitor_receive_device() without polling

Hello everybody,

the function udev_monitor_receive_device() used to be blocking a few releases
back. After the change I had to make my application poll for events.
Is there any way to to get a blocking behavior and make it work without
polling?
--

-- 
Schoene Gruesse
Chris
--
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

Building using older kernel headers

Hi all,

I am trying to build udev 172 using a toolchain which uses a 2.6.32
(or older). The previous version I tested (v114) compiled fine, and
the newer version (V172) does not compile since it needs
BTN_TRIGGER_HAPPY available at linux/input.h

My options are:

1) Use a new toolchain
2) Use an older version (which one..?)
3) Patch udev for cases in which the symbol in sot found
3.a) define the symbol locally
3.b) #ifdef that offending code out

I currently chose to to 3.a, which seems to work for now, even though
I am running under kernel 2.6.32 (which does not support the joystick
event which triggered this issue). I think 3.b can be a good idea, and
I know that even using a newer toolchain works for me, but I would
like to keep the toolchain.

Which is the newest udev version you can recommend me?
Will you accept such patch, for 3.a, or 3.b?

- diego

Only in udev-172/extras/input_id/: .deps
Only in udev-172/extras/input_id/: .dirstamp
Only in udev-172/extras/input_id/: input_id

SATA card insertion crashes if wifi active

  hi,

i am developing PCIe hotplug driver on mpc8315erdb. the hotplug 
functionality works fine if wifi (libertas) driver is not loaded. once 
libertas driver (uses SPI) is loaded, insertion or removal of SATA card 
results in an unrecoverable kernel crash. following is the error log.
-----------------------------------------------------------------------------------------------------------------------------------------
-sh-2.05b# PCIE Card Inserted to Slot 0
pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:01:00.0: PCI bridge to [bus 02-ff] (subtractive decode)
pci 0001:02:00.0: BAR 6: assigned [mem 0x40000000-0x4000ffff pref]
pci 0001:02:00.0: BAR 5: assigned [mem 0x40010000-0x40011fff]
pci 0001:02:00.0: BAR 5: set to [mem 0x40010000-0x40011fff] (PCI address 
[0x40010000-0x40011fff]
pci 0001:02:00.1: BAR 4: assigned [io  0xff7fa000-0xff7fa00f]
pci 0001:02:00.1: BAR 4: set to [io  0xff7fa000-0xff7fa00f] (PCI address 
[0x1000-0x100f]
pci 0001:02:00.1: BAR 0: assigned [io  0xff7fa010-0xff7fa017]
pci 0001:02:00.1: BAR 0: set to [io  0xff7fa010-0xff7fa017] (PCI address 
[0x1010-0x1017]
pci 0001:02:00.1: BAR 2: assigned [io  0xff7fa018-0xff7fa01f]
pci 0001:02:00.1: BAR 2: set to [io  0xff7fa018-0xff7fa01f] (PCI address 
[0x1018-0x101f]
pci 0001:02:00.1: BAR 1: assigned [io  0xff7fa020-0xff7fa023]
pci 0001:02:00.1: BAR 1: set to [io  0xff7fa020-0xff7fa023] (PCI address 
[0x1020-0x1023]
pci 0001:02:00.1: BAR 3: assigned [io  0xff7fa024-0xff7fa027]
pci 0001:02:00.1: BAR 3: set to [io  0xff7fa024-0xff7fa027] (PCI address 
[0x1024-0x1027]
pci 0001:01:00.0: PCI bridge to [bus 02-02]

udev rule matching using ENV

Dear list

i am trying to create a udev rule which executes a script whenever a usb 
stick is removed with a particular uuid

The uuid is changeable and we have a common settings file which exports 
the UUID from the usb partition.

What i would like is to import the UUID from the settings file and match 
that with the actual ID_FS_UUID with the remove action.

So i created 99-remove-usb.rules with the following contents

IMPORT{program}="/usr/local/bin/usb-stick-uuid.sh"
ACTION=="remove", ENV{ID_FS_UUID}=="ENV{MY_UUID}", 
RUN+="/usr/local/bin/usb-removed.sh"

The program usb-stick-uuid.sh now only echo's:
MY_UUID=ff744c66-3671-447c-8fa0-d96fc6f82352
and nothing else.
But it does never match.

When i enter the uuid by hand in the rule it does work:
ACTION=="remove", 
ENV{ID_FS_UUID}=="ff744c66-3671-447c-8fa0-d96fc6f82352", 
RUN+="/usr/local/bin/usb-removed.sh"

Am i doing something wrong or is it just the way it works? I also could 
not find any example on the internet matching two ENV strings.

Overriding a keymap file

Sometimes the administrator wants to override the relevant file
in (on Debian:) /lib/udev/keymaps/.  It would be convenient if this
could be done by creating a separate file under SYSCONFDIR,
i.e., under /etc, which would contain only the entries that the
admin wants to change.

For example, /lib/udev/keymaps/module-lenovo contains 16 lines.
Suppose the admin wants to change

    0x13 zoom

to

    0x13 search

If he changes /lib/udev/keymaps directly then his changes will
be overwritten by his packaging system on the next upgrade
of the udev package.  So that is not a reasonable course of action.

He does have the alternative of adding a udev rules file to
(on Debian) /etc/udev/rules.d but this is much less convenient
since it has to duplicate significant amounts of udev code from
(on Debian) /lib/udev/rules.d/95-keymap.rules.

As an example of how support for a "keymap override" file
could be added I attach a patch.  It has been tested and works
on my Ubuntu 11.04 system but I don't know how well it conforms
to applicable coding standards.

Should "keymap override" support be added to udev?  And is my

Re: detection usb camera devices in my own application

On Fri, 22 Jul 2011, Sudarshan Jagadale wrote:

> we can not install two camera kernel module at same time....
>
> if logitech QuicCam (ko - uvcvideo) and quanta camera (/uvcvideo.ko) they
> need to install using modprobe uvcvideo and insmode uvcvideo.ko .....if
> first is installed then we nned to remove it usng rmmod to install
> other...else system will give error  of already presnet...

> I get following error if i try second kernel module to install..
> 
> *insmod: error inserting '/home/manjiri/uvc_video_2.6.*
> 
> *32_21/uvcvideo.ko': -1 File exists*

This looks like you are trying to install the same module twice.  What 
makes you think "insmod uvcvideo.ko" is any different from "modprobe 
uvcvideo"?

> after long discussion with you it seems that we need to have own kernel
> mdoule to  write the hotplug device detection utility?
> 
> there is other way of /sys/bus/usb/device but it is not achivable....since
> there are lots of direcotry and we need to look for all direcoties with  no
> ':' and 'usb' name?

If you think that's too hard to program, maybe you can find someone 
else to write the program for you.

Alan Stern

Re: detection usb camera devices in my own application

On Thu, Jul 21, 2011 at 13:12, Sudarshan Jagadale <snjagadale <at> gmail.com> wrote:
> some how i have to create all the information that  present in
> /proc/bus/input/devices if camera driver is not installed...
> because this information is really neccesary to use perticular camera device
> is 2-3 cameras are connected at single time ...

'Create' this information? Where do you want to create it?

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

Re: detection usb camera devices in my own application

On Thu, 21 Jul 2011, Sudarshan Jagadale wrote:

> I want to use these camera in my frame work so i need to use /dev/video0
> device and those are mapped at /proc/bus/input/devices.. but if some one
> removes kernel module to use another kernel module for another camera then
> this information lost and again regenerats it for another camera... \
> 
> my requirment is to support the multiple camera types on single system...
> like i want to support logitech camera and quanta camera ...and both has
> their own Kernel  driver module....
> 
> so there will  be rmmod for one kernel module and insmod for another one...

Why?  Can't you have both kernel modules loaded at the same time?

> so instead of using information from /proc/bus/input/devices i have to
> generats it from usb driver so that it will not lost after kernel driver
> removed...
> 
> basically there are two main infromation in addition of vendor and product
> those are bus_info and device name ..i have no clue how to generate bus info

What do you mean by "bus info"?

Alan Stern

--
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