headers
juuso.alasuutari | 1 May 2006 02:04

cdrom_id availability

Hello. There are lines like this in the Source Mage default rules file:

BUS=="scsi",    KERNEL=="sr[0-9]*", ACTION=="add", IMPORT="cdrom_id --export
$tempnode"

cdrom_id is installed in /lib/udev/, but that directory is not in $PATH. My
question is: Will that rule actually execute cdrom_id, or should it be changed
to ...="/lib/udev/cdrom_id --export $tempnode"?

Juuso

----------------------------------------------------------------
This mail sent through L-secure: http://www.l-secure.net/

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply | 1 comment |
headers
Kay Sievers | 1 May 2006 02:16

Re: cdrom_id availability

On Mon, May 01, 2006 at 03:04:13AM +0300, juuso.alasuutari <at> tamperelainen.org wrote:
> Hello. There are lines like this in the Source Mage default rules file:
> 
> BUS=="scsi",    KERNEL=="sr[0-9]*", ACTION=="add", IMPORT="cdrom_id --export
> $tempnode"
> 
> cdrom_id is installed in /lib/udev/, but that directory is not in $PATH. My
> question is: Will that rule actually execute cdrom_id, or should it be changed
> to ...="/lib/udev/cdrom_id --export $tempnode"?

If the value does not start with a '/', the program is searched in
/lib/udev. All udev pathes have to be absolute ones or only the
single program name and then live in /lib/udev. $PATH is completely 
ignored.

Kay

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
Permalink | Reply | 0 comments |
headers
Hai Zaar | 1 May 2006 17:06
Picon

rules for EVMS volumes

Hi!

I've wanted EVMS volumes to show in /dev/disk. So I've created the
following rules and placed them in /etc/udev/rules.d/61-evms.rules
(right after persistent rules).

KERNEL=="dm-[0-9]*",    ACTION=="add", IMPORT{program}="/bin/bash -c
'echo DMNAME=$$(/sbin/dmsetup info -c --noopencount --noheadings -o
name -j %M -m %m)'"
KERNEL=="dm-[0-9]*",    ACTION=="add", IMPORT{program}="/sbin/vol_id
--export $tempnode"
KERNEL=="dm-[0-9]*",    ACTION=="add",
ENV{ID_FS_UUID}=="?*",PROGRAM="/bin/test -e /dev/evms/$env{DMNAME}",  
     SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
KERNEL=="dm-[0-9]*",    ACTION=="add",
ENV{ID_FS_LABEL_SAFE}=="?*",PROGRAM="/bin/test -e
/dev/evms/$env{DMNAME}", 
SYMLINK+="disk/by-label/$env{ID_FS_LABEL_SAFE}"

Although it seems to work, I'd like to hear your comments if you have any.

Also I've wrote a small article
http://zaar.blogspot.com/2006/05/fine-grained-evms-device-nodes.html
which explains why and how I've come to this.
---------------------------------------------------
System: LFS-based, kernel 2.6.15, udev-0.8.1
--
Zaar

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Danny Budik | 1 May 2006 17:39

Re: Accessing usb devices with USBDEVFS

Kay Sievers wrote:
> On Fri, Apr 28, 2006 at 01:44:08PM -0400, Danny Budik wrote:
>   
>> I have a question that may or may not be related to hotplugging. I have 
>> noticed that when I plug in a USB device, it takes about 5 seconds for 
>> it to show up in /proc/bus/usb/001/xxx. I am using HAL to recognize when 
>> a USB device is plugged in and USBDEVFS to communicate with my device.
>>
>> When I plug it in, dbus/HAL instantly recognizes it and sends me a 
>> message.  But when I make the function call to open it (using fopen on 
>> the file above) I get an error that the device is not found. In fact, it 
>> takes about 5 seconds for the device to show up in the /proc/bus/usb/ 
>> directory so I have to place a sleep(5) line in my C code before I am 
>> able to open the device.
>>
>> My test machine is a PIII 733 with FC4, latest kernel, so it is a 
>> relatively slow machine. Is there a way to predict the time that it 
>> takes for the device to be accessible with USBDEVFS so that I don't have 
>> to hardcode the sleep statement?
>>     
>
> Recent systems don't use /proc for usb access anymore and real device
> nodes in /dev/bus/usb instead. HAL sends "usbraw" device anouncements with
> "linux.device_file" as a property when the device is created.
>
> Kay
So is there a way then to read from the /dev/bus/usb? Like I mentioned 
in the parent post, I am just using fopen, and the functions provided in 
usbdevice_fs.h and usb.h to read data from the usb device. The device is 
a proprietary sensor that my company makes. Is there a
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alexander E. Patrakov | 1 May 2006 17:43
Picon

Re: rules for EVMS volumes

Hai Zaar wrote:
> Hi!
> 
> I've wanted EVMS volumes to show in /dev/disk. So I've created the
> following rules and placed them in /etc/udev/rules.d/61-evms.rules
> (right after persistent rules).
> 
> KERNEL=="dm-[0-9]*",    ACTION=="add", IMPORT{program}="/bin/bash -c
> 'echo DMNAME=$$(/sbin/dmsetup info -c --noopencount --noheadings -o
> name -j %M -m %m)'"
> KERNEL=="dm-[0-9]*",    ACTION=="add", IMPORT{program}="/sbin/vol_id
> --export $tempnode"
> KERNEL=="dm-[0-9]*",    ACTION=="add",
> ENV{ID_FS_UUID}=="?*",PROGRAM="/bin/test -e /dev/evms/$env{DMNAME}",  
>     SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
> KERNEL=="dm-[0-9]*",    ACTION=="add",
> ENV{ID_FS_LABEL_SAFE}=="?*",PROGRAM="/bin/test -e
> /dev/evms/$env{DMNAME}", SYMLINK+="disk/by-label/$env{ID_FS_LABEL_SAFE}"
> 
> Although it seems to work, I'd like to hear your comments if you have any.
> 
> Also I've wrote a small article
> http://zaar.blogspot.com/2006/05/fine-grained-evms-device-nodes.html
> which explains why and how I've come to this.
> ---------------------------------------------------
> System: LFS-based, kernel 2.6.15, udev-0.8.1

Why does one ever need persistent names for DM devices? The default names (with
LVM2, this is something like /dev/mainvg/root) created by userspace packages are
already persistent enough to survive the move from old IDE drivers (that treat
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hai Zaar | 1 May 2006 17:45
Picon

Re: rules for EVMS volumes

On 5/1/06, Alexander E. Patrakov <patrakov <at> ums.usu.ru> wrote:
>
> Why does one ever need persistent names for DM devices? The default names (with
> LVM2, this is something like /dev/mainvg/root) created by userspace packages are
> already persistent enough to survive the move from old IDE drivers (that treat
> IDE disks as /dev/hdX) to libata (which treats the same drivers as /dev/sdX)
> without a single change to any configuration file.
Well, my intention is to see all of my attached hard disks under
/dev/disk/, particularly, under /dev/disk/by-uuid. So if today I use
EVMS, I'd like EVMS stuff to arrange appropriate links in /dev/disk.
If tomorrow I switch to LVM2, I'd like LVM2 to do the same.

>
> Moreover, it is Just Wrong (TM) to have /dev/dm-X device nodes, because:
>
> 1) As already explained, userspace (e.g., dmsetup, vgmknodes, evms_activate,
> etc.) already creates the correct nodes in the /dev/mapper directory and
> symlinks to such nodes
with EVMS its actually /dev/evms/...

>
> 2) The mere existence of /dev/dm-* breaks LILO (nodes in /dev/mapper are OK).
>
> So, the only correct solution in this situation is implemented by Debian:
>
> 1) Prevent udev from creating device-mapper nodes at all, because it is the task
> for other packages:
>
> KERNEL=="dm-[0-9]*",            NAME=""
> KERNEL=="device-mapper",        NAME="mapper/control"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 1 May 2006 18:57
Gravatar

Re: Accessing usb devices with USBDEVFS

On Mon, May 01, 2006 at 11:39:11AM -0400, Danny Budik wrote:
> Kay Sievers wrote:
> >On Fri, Apr 28, 2006 at 01:44:08PM -0400, Danny Budik wrote:
> >  
> >>I have a question that may or may not be related to hotplugging. I have 
> >>noticed that when I plug in a USB device, it takes about 5 seconds for 
> >>it to show up in /proc/bus/usb/001/xxx. I am using HAL to recognize when 
> >>a USB device is plugged in and USBDEVFS to communicate with my device.
> >>
> >>When I plug it in, dbus/HAL instantly recognizes it and sends me a 
> >>message.  But when I make the function call to open it (using fopen on 
> >>the file above) I get an error that the device is not found. In fact, it 
> >>takes about 5 seconds for the device to show up in the /proc/bus/usb/ 
> >>directory so I have to place a sleep(5) line in my C code before I am 
> >>able to open the device.
> >>
> >>My test machine is a PIII 733 with FC4, latest kernel, so it is a 
> >>relatively slow machine. Is there a way to predict the time that it 
> >>takes for the device to be accessible with USBDEVFS so that I don't have 
> >>to hardcode the sleep statement?
> >>    
> >
> >Recent systems don't use /proc for usb access anymore and real device
> >nodes in /dev/bus/usb instead. HAL sends "usbraw" device anouncements with
> >"linux.device_file" as a property when the device is created.
> >
> >Kay
> So is there a way then to read from the /dev/bus/usb? Like I mentioned 
> in the parent post, I am just using fopen, and the functions provided in 
> usbdevice_fs.h and usb.h to read data from the usb device. The device is
(Continue reading)

Permalink | Reply | 5 comments |
headers
Danny Budik | 1 May 2006 21:00

Re: Accessing usb devices with USBDEVFS


>> So is there a way then to read from the /dev/bus/usb? Like I  
>> mentioned
>> in the parent post, I am just using fopen, and the functions  
>> provided in
>> usbdevice_fs.h and usb.h to read data from the usb device. The  
>> device is
>> a proprietary sensor that my company makes. Is there a
>> manual/documentation about how to do this the more "modern" way?
>
> No, that's still the correct way.  If you use libusb, none of your  
> code
> changes at all.   If you are using "raw" usbfs, then just open a
> different file.
>
> Hope this helps,
>
> greg k-h
>
So that brings me to my next question. I guess I didn't know that  
libusb existed and wrote my own interface functions. Is it because of  
this that whenever I access the USB device, I must be root? Obviously  
that's a security issue. In other words, can I read/write to my USB  
device as a user using libusb?

Danny Budik
Inductive Signature Technologies
Systems Engineer

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Greg KH | 1 May 2006 21:06
Gravatar

Re: Accessing usb devices with USBDEVFS

On Mon, May 01, 2006 at 03:00:17PM -0400, Danny Budik wrote:
> 
> >>So is there a way then to read from the /dev/bus/usb? Like I  
> >>mentioned
> >>in the parent post, I am just using fopen, and the functions  
> >>provided in
> >>usbdevice_fs.h and usb.h to read data from the usb device. The  
> >>device is
> >>a proprietary sensor that my company makes. Is there a
> >>manual/documentation about how to do this the more "modern" way?
> >
> >No, that's still the correct way.  If you use libusb, none of your  
> >code
> >changes at all.   If you are using "raw" usbfs, then just open a
> >different file.
> >
> >Hope this helps,
> >
> >greg k-h
> >
> So that brings me to my next question. I guess I didn't know that  
> libusb existed and wrote my own interface functions. Is it because of  
> this that whenever I access the USB device, I must be root? Obviously  
> that's a security issue. In other words, can I read/write to my USB  
> device as a user using libusb?

No, that is what this change in moving the usbfs files from
/proc/bus/usb/ to /dev/bus/usb enables now.  You can create a simple
udev rule to give your device the proper owner:group permissions and
then you will not have to be root to use your program.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kay Sievers | 1 May 2006 21:09

Re: Accessing usb devices with USBDEVFS

On Mon, May 01, 2006 at 03:00:17PM -0400, Danny Budik wrote:
> 
> >>So is there a way then to read from the /dev/bus/usb? Like I  
> >>mentioned
> >>in the parent post, I am just using fopen, and the functions  
> >>provided in
> >>usbdevice_fs.h and usb.h to read data from the usb device. The  
> >>device is
> >>a proprietary sensor that my company makes. Is there a
> >>manual/documentation about how to do this the more "modern" way?
> >
> >No, that's still the correct way.  If you use libusb, none of your  
> >code
> >changes at all.   If you are using "raw" usbfs, then just open a
> >different file.
> >
> >Hope this helps,
> >
> >greg k-h
> >
> So that brings me to my next question. I guess I didn't know that  
> libusb existed and wrote my own interface functions. Is it because of  
> this that whenever I access the USB device, I must be root? Obviously  
> that's a security issue. In other words, can I read/write to my USB  
> device as a user using libusb?

That has nothing to do with the way you access the device it's not
different for libusb or a simple open(). The usual way is to change
the owner/group of the device node or add an user ACL to the
node when it appears and grant access that way to normal users.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane