Ananth N Mavinakayanahalli | 1 Jun 2005 19:42
Picon

[ANNOUNCE] Libsysfs-v1.3.0

Hi,

Here goes v1.3.0 of libsysfs. Libsysfs is shipped as part of the
sysfsutils package and is available for download at

	http://linux-diag.sourceforge.net

Please note that distributions that package udev to depend on the
standalone version of libsysfs will need to upgrade to v1.3.0 in
lieu of changes in the kernel during the 2.6.12-rc* series.

This is a bugfix only release and will be the last of the 1.x releases.
v2.0 of the library is currently under development and contains quite
a few cleanups with respect to the data structures as also the way
attributes are populated. 

Udev has been shipping with a stripped down version of v2.0 for some
time now and has resulted in significant improvement in udevstart
speed. The current v2.0 snapshot is available on sourceforge CVS under
the branch sysfsutils-2_0_0.

Regards,
Ananth

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
(Continue reading)

Patrick Mansfield | 1 Jun 2005 03:00
Picon
Favicon

Re: Wishlist + bugs for udev-058

On Wed, Jun 01, 2005 at 12:10:37AM +0200, Kay Sievers wrote:
> On Tue, May 31, 2005 at 08:54:44PM +0200, Bodo Eggert wrote:
> > 
> > Wish: Make sg devices be a child of their corresponding devices
> 
> That's a kernel thing. Try to convince the scsi-guys. :)

I assume he means put sg under sd, that can't be done as sg is at the same
level as sd, and can even show up if sd is not loaded (and shows up for
all scsi devices, not just block ones ...).

If all your scsi devices are block devices, you likely can run without
loading sg, and just send SG_IO ioctl's to the block device.

sg does show up under the sys device tree, as the "generic" link:

[elm3b79 0:0:0:0]$ ls -l /sys/devices/pci0000:00/0000:00:0a.0/host0/target0:0:0/0:0:0:0/generic
lrwxrwxrwx    1 root     root            0 May 31 17:54
/sys/devices/pci0000:00/0000:00:0a.0/host0/target0:0:0/0:0:0:0/generic -> ../../../../../../class/scsi_generic/sg0

-- Patrick Mansfield

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
Greg KH | 1 Jun 2005 23:08
Gravatar

Re: [patch 0/3] sysfs permissions

On Tue, May 31, 2005 at 10:36:42AM +0530, Maneesh Soni wrote:
> Hi
> 
> Following this post, are the three patches implementing setattr functionality 
> for sysfs objects. This allows sysfs objects to get their default attributes 
> like owner, group, permission modes modified. The changed attributes are 
> saved in a struct iattr linked with struct sysfs_dirent for the corresponding 
> object. This keeps the inode attributes saved even if inode/dentry is 
> evacuated due to memory pressure or umount. The struct iattr is allocated only 
> for those sysfs objects for which inode attributes are getting changed.
> 
> I did the following test for verifying the patchset
> 
> [root <at> llm01 ~]# ls -l /sys/class/net/dummy0/address
> -r--r--r--  1 root root 4096 May 31 10:32 /sys/class/net/dummy0/address
> [root <at> llm01 ~]# chmod +w /sys/class/net/dummy0/address
> [root <at> llm01 ~]# ls -l /sys/class/net/dummy0/address
> -rw-r--r--  1 root root 4096 May 31 10:32 /sys/class/net/dummy0/address
> [root <at> llm01 ~]#
> [root <at> llm01 ~]# chown maneesh /sys/class/net/dummy0/address
> [root <at> llm01 ~]# ls -l /sys/class/net/dummy0/address
> -rw-r--r--  1 maneesh root 4096 May 31 10:32 /sys/class/net/dummy0/address
> [root <at> llm01 ~]#
> [root <at> llm01 ~]# chgrp maneesh /sys/class/net/dummy0/address
> [root <at> llm01 ~]# ls -l /sys/class/net/dummy0/address
> -rw-r--r--  1 maneesh maneesh 4096 May 31 10:32 /sys/class/net/dummy0/address
> [root <at> llm01 ~]#
> [root <at> llm01 ~]# umount /sys
> [root <at> llm01 ~]# ls -l /sys/class/net/dummy0/address
> ls: /sys/class/net/dummy0/address: No such file or directory
(Continue reading)

Rajat Jain | 2 Jun 2005 13:21
Picon

Faking a Hot-Unplug event in kernel 2.6

Hi,

Please pardon me if this is not the right list for this post. I'm
using 2.6 Kernel. I'm having a (Hot-pluggable) Qlogic HBA plugged into
a PCI Express Slot.

I want to fake an hot-unplug event for this HBA, without physically
removing it from the slot. Basically what I want is that while the HBA
is still physically present at the slot, I want to fire a command /
program that would fake the hot-unplug event for this slot, and thus
will deregister the HBA from Linux. Ideally, I want to do this from
userspace. But if it is not possible, then I can go for a kernel
module as well.

I think that this feature was made available by "Fake PCI Hot plug
controller Driver", but I believe that can only be used if my system
does not have REAL hot-plugging slots. Can "Fake PCI Hot-plug
Controller Driver (fakephp.ko)" and "PCI Express Hot-plug Controller
Driver (pciehp.ko)" Co-exist ??? (So that I can manually give fake
unplug event and THEN remove the device; While hot-plugging, I want
PCI Express HPC driver to take care of every thing)

Is it possible to do what I am trying to do?

TIA,

Rajat

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
(Continue reading)

Dan Gray | 2 Jun 2005 13:37

It just works - USB removal script suggestion/patch

Hi,
 I've been playing around with hotplug for a while now and am not entirely happy with the way that usb.agent
handles removal requests.
 The documentation is fairly wooly on the subject, and initially it appears as though the $ACTION received
by the specified agent script can be one of 'add' or 'remove' - this is of course not the case (as far as I can
see). While we should all RTFM this required a trawl through the source and the skills of an experianced
user. This patch is aimed at 'Desktop Linux' where a user would presumably have admin rights but not
necessarily alot of experiance and may need a clear model within which to place the necessary removal
script without playing with the hotplugging 'base' scripts and damaging the system.

 So I tracked down the /var/run/usb/ based 'remover' script and the system works very well. I think that
there is a problem however with the functionality of this system for the non-skilled user, in that the name
for the script is not intuitive and it must be created every time that the usb device is inserted (if the
script is trivial that a simple 'echo' from the insertion script can do it, if non-trivial a script must be
copied from elsewhere), this seems over complicated and, should a user wish to create a removal script, it
requires that they edit the agent script in /etc/hotplug/usb/ directly, hardly desirable.

 The last few months we've been hearing alot about 'it just works', and trying to simplify some of linux'
functions and so heres my proposition as a patch to usb.agent: 

---------------------------
<     basicVendor=$1
<     basicProduct=$2
< 
379d373
< 
443,459d436
< 
<     usb_convert_vars
< 
(Continue reading)

Rajat Jain | 2 Jun 2005 13:52
Picon
Favicon

(no subject)

Hi,

I'm using 2.6 Kernel. I'm having a (Hot-pluggable)
Qlogic HBA plugged into a PCI Express Slot. 

I want to fake an hot-unplug event for this HBA,
without physically removing it from the slot.
Basically what I want is that while the HBA is still
physically present at the slot, I want to fire a
command / program that would fake the hot-unplug event
for this slot, and thus will deregister the HBA from
Linux. Ideally, I want to do this from userspace. But
if it is not possible, then I can go for a kernel
module as well.

I think that this feature was made available by "Fake
PCI Hot plug controller Driver", but I believe that
can only be used if my system does not have REAL
hot-plugging slots. Can "Fake PCI Hot-plug Controller
Driver" and "PCI Express Hot-plug Controller Driver"
Co-exist ??? (So that I can manually give fake unplug
event and THEN remove the device; While hot-plugging,
I want PCI Express HPC driver to take care of every
thing)

Is it possible to do what I am trying to do?

TIA,

Rajat
(Continue reading)

Stefan Schweizer | 2 Jun 2005 14:59
Picon

Re: It just works - USB removal script suggestion/patch

Did you look into dbus/hal yet?
dbus/hal works in userspace and should do what you want :)

- Stefan

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
Dan Gray | 2 Jun 2005 17:09

Re: It just works - USB removal script suggestion/patch


You wrote:
> Did you look into dbus/hal yet?
> dbus/hal works in userspace and should do what you want :)
> 
> - Stefan

 I did, but they present three problems:

 First, it's an extra daemon/configuration burden

 Second, the userspace function only works for processes you own. I wanted to kill irattach when I removed a
USB dongle, hal/dbus would have needed additional configuration.

 This just seems like a sensible, K.I.S.S. approach to the problem within the hotplug framework with no need
for additional configuration. I'm thinking of patching my usb.agent to do the same for inserts. I have to
say I even dislike the existing system of /etc/hotplug/usb scripts as it relies on a properly condigured
usb map file which seems superfluous to most peoples needs (i.e Plug in a device, write a script with a
unique name, put it in the right place, so again, no need to write/edit an additional file.)

  Dan

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
Daniel Drake | 3 Jun 2005 00:19
Picon
Favicon

[PATCH] Fix up 'broken' permissions

I'm not sure whether this is intentional, but 2 rules specify a group and
permissions of 0600 (so the group change effectively does nothing, unless the
permissions were to be changed).

The one dealing with usb serial is most important here.. Many palm-style
devices use ttyUSB nodes to communicate with the host computer. Currently, the
user can't use the nodes, even when in the tty group.

Attachment (permissions-fix.patch): text/x-patch, 853 bytes
Melinda Taylor | 3 Jun 2005 06:58
Picon
Picon

update

Hello,

When I plug my external firewire disk - a sohotank U6 USB2.0/FW800 with 
400GB SATA drive inside - into my fresh install of fedora core 3 i see 
the message below. I also plugged in a Sarotech (FHD-353) containing a 
120GB IDE drive and that was detected and mounted just fine on the 
server so I presume it isn't recgonising something specific to the 
external enclosure? The messages said to "please report to 
<linux-hotplug-devel <at> lists.sourceforge.net>" and so I am. Please let me 
know if you need anymore information.

Many Thanks,

Melinda

May 27 13:25:34 localhost kernel: ieee1394: Error parsing configrom for node
0-01:1023
May 27 13:25:34 localhost kernel: ieee1394: Error parsing configrom for node
0-00:1023
May 27 13:25:42 localhost wait_for_sysfs[4452]: error: unknown bus, please
report to <linux-hotplug-devel <at> lists.sourceforge.net> 'ieee1394'
May 27 13:25:42 localhost wait_for_sysfs[4452]: either wait_for_sysfs 
(udev 039)
needs an update to handle the device
'/devices/pci0000:00/0000:00:1e.0/0000:02:01.1/0000:07:00.0/fw-host0/0030e002e000223c'
properly (unknown bus) or the sysfs-support of your device's driver 
needs to be
fixed, please report to <linux-hotplug-devel <at> lists.sourceforge.net>
May 27 13:25:42 localhost kernel: scsi3 : SCSI emulation for IEEE-1394 SBP-2
Devices
(Continue reading)


Gmane