Stop hald probing of certain devices (was: cdrecord floating point exception)
Am 04.02.2009, 10:06 Uhr, schrieb Thomas Schmitt <email@example.com>:
Rob Bogus wrote:
There is no doubt that a system can run without hald, if you assume
administrator is willing to do the same things by hand, and the user
understands how to do all the things which hald typically does.
Personally i am a non-admin and leave
my SuSEs quite as they come out of the
box. Up to one year ago i had no hald
running (SuSE 9 with kernel 2.4) and really
did not miss it in any way.
The only device automat i want is the
USB plug-and-pull recognizer. That worked
already on the old SuSEs without hald.
I am not curious enough to explore whether
hald is involved meanwhile.
What i experienced at the first day of 10.2 was
CD-RW burn failure due to hald-addon-storage
processes. One per drive. They confessed by
telling the drive addresses in ps output.
Although i do not see it as necessary and do
not like its behavior, i acknowledge that
hald is there and that a burn program should
seek coordination with it.
either using applications which understand hald
or making a simple one time change in the hald config.
Any pointer to tutorial documentaion is
higly welcome. Topics of interest:
How to keep hald away from the CD burner ?
(I would point from libburn docs to that.)
Adapt that and you'll end up with something like
<?xml version="1.0" encoding="UTF-8"?>
<!-- we want hald to skip cdrom drives -->
<match key="storage.drive_type" string="cdrom">
<merge key="info.ignore" type="bool">true</merge>
That you install as - for instance - 10-no-cdroms.fdi into
/usr/share/hal/fdi/preprobe/20thirdparty - however, that will likely break
media detection on lots of typical distributions.
Let me say that I find intimidating how much XML configuration hal
apparently needs on a typical distro...
- Burn programmer (C language, console environment):
How to negociate with hald in order to either
get exclusivity at the drive or to learn that
it is already occupied ?
What i would deem not acceptable for a burn program:
- unstable API form and semantics
- fat desktop libraries
- non-C languages
That's for squeezing out of the hal maintainers ;-)