[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: More on hotplug issue w/HAL
- From: Matthew Mastracci <matt aclaro com>
- To: David Zeuthen <david fubar dk>
- Cc: xdg-list freedesktop org
- Subject: Re: More on hotplug issue w/HAL
- Date: Mon, 05 Jan 2004 11:06:12 -0700
David Zeuthen wrote:
Did you happen to take a look at the SCSI UDI LUN modifications I sent
with my last message (they may have gotten drowned out in the log
messages :)). Those fixed the missing block device problem I was having
both on startup and hotplug add/remove.
I've done some more thinking to create a more complete (and probably
more correct) solution:
I was thinking that a scsi_device needs to have the following attributes
so that they don't errorneously get merged into a single SCSI interface
node.
(parsed from /path/to/device/host:channel:id:lun in sysfs)
scsi_device.host = n
scsi_device.channel = n
scsi_device.id = n
scsi_device.lun = n
scsi_host should have:
(parsed from the /path/to/device/hostn path in sysfs)
scsi_host.host = n
These will uniquely identify all scsi_host and scsi_device nodes within
a single device. They can then be appended to the appropriate UDI for a
scsi_host/scsi_device node.
Ok, basically you need to check that everything works on both hald
startup (when detecting all the devices) and on hotplug add/remove.
One thing I've been missing from your debug logs are lines like this
[I] linux/linux_osspec.c:529 handle_udev_node_created() : udev
NodeCreated: /udev/sda /initrd/sys/block/sda
[I] linux/linux_osspec.c:563 handle_udev_node_created_found_device() :
Setting block.device=/udev/sda for
udi=/org/freedesktop/Hal/devices/temp/47
[I] linux/linux_osspec.c:529 handle_udev_node_created() : udev
NodeCreated: /udev/sda1 /initrd/sys/block/sda/sda1
[I] linux/linux_osspec.c:563 handle_udev_node_created_found_device() :
Setting block.device=/udev/sda1 for
udi=/org/freedesktop/Hal/devices/temp/48
on hotpluggin - the debug means that hald has received a dbus signal
from the udev service associating a device file with a sysfs path. You
might want to check that the file
/etc/dbus-1/system.d/udev_sysbus_policy.conf
exist on your system. It seems to be missing from an RPM I built from
udev-012, but that may be my own fault.
That file is missing from my system. I used "make install" +
checkinstall to install HAL/dbus/udev. I was getting a dbus permissions
error on connection when starting udev earlier. After moving that file
to system.d, it looks like everything is working great!
I'm currently working on this using polling and ioctl(2) on the cdrom
device file (like magicdev). Unfortunately I won't have time to hack on
this before tomorrow evening due to other commitments in real life. If
you write code to detect media change for your devices, we should
definitely put it in HAL.
(btw, some day we want to use the dbus events that Rob Love's kernel
will be generating instead of polling)
I'm going to try sniffing the USB data stream to see if I get any sort
of notification that the device media has changed. If not, I'll
probably have to use your polling code to perform the same tests to
detect it. I'll keep you posted on what I discover.
It's the maximum amount of time, don't worry. My favourite test case is
hotplugging this tree of devices
and this take a fair amount of time (~20 sec) on my old laptop mostly
due to swapping (it's a 128MB box running Fedora) and devlabel being
invoked all the time. It does work however, even though the devices
appear in a funny order.
It takes one heckova long time for the devices to appear in HAL for
myself. I'm hoping that HAL and udev might make a lot of the hotplug
nastiness (updfstab + devlabel + pam_console_apply) go away. ;)
Matt.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]