|
Bugzilla – Full Text Bug Listing |
| Summary: | scsi generic devices needed in hal | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Ludwig Nussel <lnussel> |
| Component: | Basesystem | Assignee: | Danny Kukawka <dkukawka> |
| Status: | VERIFIED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | ||
| Version: | Alpha 4 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
export scsi_generic devices
add scsi.type, scsi.vendor, scsi.model |
||
@Kay: what do you think? Yes, would be nice to have it. Created attachment 62018 [details]
export scsi_generic devices
Patch to create device object for scsi_generic devices.
updated to new HAL version, fixed now. Ok, the device is there but I don't know how to match it. It's a sibling of the cdrom device and lacks any property that suggests that it's a scsi generic device for a cdrom. Would it be possible to somehow create a connection between srX and sgX so I can match them via fdi file? Hmm, both have the same "info.parent", can't you use this? We maybe could add a property with the udi of the related block device, but are this devices alway blockdevices? @Kay: any ideas? Generic devices are independend, they are a charcter device and can exist even without any block device, like old scsi scanners. There is no event order we can depend on, so connecting childs to each other is not easy. If you can match them over the sam info.parent I close the bug I don't see how that's possible in an fdi file. If I could use something like @info.parent:@block:vendor_id for matching I might be able to change the fdi files to install ACLs on scsi generic devices. As it is atm I don't see a way to avoid libresmgr and the scsi flag. Created attachment 64267 [details]
add scsi.type, scsi.vendor, scsi.model
This adds: scsi.type, scsi.vendor, scsi.model to the scsi parent, which should work around the currently impossible "cross match" to a "sister device".
linux.subsystem = 'scsi' (string)
scsi.type = 'cdrom' (string)
scsi.vendor = 'MATSHITA' (string)
scsi.model = 'DVD-RAM UJ-822S' (string)
info.product = 'SCSI Device' (string)
info.linux.driver = 'sr' (string)
Comitted to HAL CVS. works. Breaks cdrecord though as resmgr patch causes cdrecord to not evaluate sg devices by traditioinal means when running as non-root. I can fix that but I fear other packages could have similar "features". hal-resmgr and fixed cdrecord submitted, please submit hal package with that patch. Added patch for Beta2 |
To be able to get rid of resmgr's special scsi handling we need scsi generic devices listed in hal. sysfs looks like this: > l -R /sys/class/scsi_generic /sys/class/scsi_generic: insgesamt 0 drwxr-xr-x 3 root root 0 2006-01-03 14:04 ./ drwxr-xr-x 26 root root 0 2006-01-03 14:04 ../ drwxr-xr-x 2 root root 0 2006-01-03 14:30 sg0/ /sys/class/scsi_generic/sg0: insgesamt 0 drwxr-xr-x 2 root root 0 2006-01-03 14:30 ./ drwxr-xr-x 3 root root 0 2006-01-03 14:04 ../ -r--r--r-- 1 root root 4096 2006-01-03 14:30 dev lrwxrwxrwx 1 root root 0 2006-01-03 14:30 device -> ../../../devices/pci0000:00/0000:00:1d.7/usb4/4-1/4-1:1.0/host0/target0:0:0/0:0:0:0/ --w------- 1 root root 4096 2006-01-03 14:30 uevent