[Libburn] Re: FYI: my current modifications versus CVS of 8 Dec
scdbackup at gmx.net
scdbackup at gmx.net
Mon Jan 16 03:43:02 PST 2006
> > But as said, it is the concept of mandatory bus scan which opens
> > the door for lots of trouble.
> Ok. I acknowledge that this is a problem. :)
Sorry for being so insisting.
It's just because i want to end my libburn-0.2.ts fork as
soon as possible. It keeps me from testing your recent
> How about I give you a function like...
> burn_drive_grab_by_pathname(struct burn_drive *, char *)?
> I could give a function to get the filename of the node a burn_drive *
> refers to as well.
For the needs of cdrskin it would be sufficient.
It would be the straightforward approach, even.
But rather than a new info function i would prefer to get a
struct burn_drive_info refering to a drive list with
a single item.
cdrskin currently depends on struct burn_drive_info members:
location , drive , vendor , product. Possibly i want to access
other burn_drive_info members in future.
Probably it would be better to apply the new gesture at the
level of drive scan and not of drive grab. Like:
burn_drive_scan_single(struct burn_drive_info **, char *)
Drive grabbing would be done by the usual call. If needed.
Alternatively the new grab call could return a struct burn_drive_info .
This would have still the disadvantage that i cannot access
drive properties without grabbing the drive. (cdrskin -checkdrive
currently does not need to grab.)
I have chosen the whitelist concept mainly because it
allowed me to leave the functionality of *_enumerate()
Nevertheless, it might have other useful applications.
Of all remedy ideas i still like this one best. :)
> > I had to reboot after that hwinfo-libburn collision.
> The kernel shouldn't have let you do that. Second attempt to access the
> same device should've been blocked...
> What interface does hwinfo use?
Interesting question - no idea.
I was not aware that it is dangerous.
It also performed synthetic mouse clicks and i am lucky that
no important original data got damaged ... as far as i can
see and as far as find can find.
I am reluctant to repeat that stunt. I will not perform
hwinfo any more at all. That mouse thing is unbearable.
> I'm rather stunned the drive was left in a state that -reset couldn't
It is flatly embarrassing if one has to reboot
in order to regain control over a device.
Not that i would especially blame libburn for that.
I had similar interrupt encounters with cdrecord some
years ago. (Not knowing how it would react today.)
I would hardly ever press CTRL+C on a running cdrecord
unless i planned to reboot anyway.
Nevertheless we should strive for better abort behavior
of libburn. I tried to install signal handlers in cdrskin
but could not achieve useable results up to now.
I am unable to end a burn session by something like
wait for BURN_DRIVE_IDLE
If i kill cdrskin while performing burn_disc_write()
i get two calls of the signal handler (from two threads ?)
and my call of burn_drive_cancel() obviously does not
work at all. The drive does not get idle.
burn_drive_release() accuses me of violating an assert
condition ("!d->busy") if i perform it while not
BURN_DRIVE_IDLE. The program exits, the drive LED
stays busy, the drive is unejectable.
I have to run cdrecord -abort to get the drive useable
again. This works within about 3 seconds.
Is there an equivalent to cdrecord -abort available within
libburn ? cdrskin could well need such an option.
Anybody knows some kind of tutorial how to deal with signal
handling and threads ?
The only working configuration which i could achieve is
a nearly non-interruptable cdrskin which is a pain in the
ass by itself. You press CTRL+C and it goes on and on
... until it is done on its own. No -abort needed but
a very angry user produced.
Have a nice day :)
More information about the libburn