Bug 15283 - Modify hald to act like the Solaris volume manager
Summary: Modify hald to act like the Solaris volume manager
Status: RESOLVED NOTABUG
Alias: None
Product: hal
Classification: Unclassified
Component: hald (show other bugs)
Version: unspecified
Hardware: All All
: low enhancement
Assignee: David Zeuthen (not reading bugmail)
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-31 07:06 UTC by Sam Morris
Modified: 2009-07-28 05:29 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Sam Morris 2008-03-31 07:06:24 UTC
This bug was originally reported by Joerg Schilling to the Debian bug tracking system at <http://bugs.debian.org/361643>. I think it would be inappropriate for us to modify hal as requested, so I am filing the bug upstream.

> It is obvious that hal is a non-cooperative application that interrupts
> CD/DVD-writing.
> 
> As an intermediate solution, I recommend to kill hald.
> 
> The long term solution is to fix hald to become a cooperative application.
> Here is an example for a cooperative application that the hald people don't 
> know how to do things without interrupting other applications:
> 
> http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/volmgt/
> 
> It is definitely not a solution introduce bugs into libscg in order
> to hide 90% of the problems caused by this hald bug.

Further info:

> Let me add some notes that help to understand vold and to 
> fix hald.....
> 
> Using O_EXCL is definitely not the right solution.
> 
> The right way to deal with this hald induced problem is to 
> change hald to not access the drive later than 3 seconds
> after a medium change indication has been reveived and in any
> othe case not to send any SCSI command other than INQUIRY and TEST_UNIT_READY.
> Note that even INQUIRY and TEST_UNIT_READY should not be issued more
> than once every 3 seconds.
Comment 1 Danny Kukawka 2008-04-01 12:28:46 UTC
I don't see atm the problem. You can simply lock the device and HAL stops polling the device until you remove the lock again. You can use hal-lock or hal-disable-polling (or D-Bus directly) to stop the polling. This is what AFAIK e.g. k3b do.
Comment 2 Sam Morris 2008-04-01 16:27:19 UTC
I found some more cryptic comments from Mr. Schilling on the Cdrecord Developers mailing list about what hal "should" do:

> On Linux, hald polls the wrong way and need to be fixed to only act on the 
> right status transitions. Opennin with O_EXCL is not helpful, in special
> on Linux as Linux has more than one driver for the same hardware.
>
> As long as hald on Linux has not been fixed, you need to kill hald.

and:

> O_EXCL is not a solution but creates just other different problems.
> 
> The only way do deal with the problem is to fix hald. Hald works fine on Solaris
> as on Solaris, hald gets the right events from the kernel loop in sd.c
> Hald on Linux acts on events that should be of no interests for hald.
> 
> If the hald people are interested to fix hald, I am open for a discussion.

That's about as close as I can get to finding out why he thinks O_EXCL is not the right solution...
Comment 3 Danny Kukawka 2009-07-28 05:29:01 UTC
Close the bug as NOTABUG since I can't see what's the problem/bug here. It works for me.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.