[Libburn] Re: FYI: my current modifications versus CVS of 8 Dec

[scdbackup at gmx.net]

Hi,
 
> > 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
efforts.

 
> 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()
undamaged.
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 
> clear.

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
  burn_drive_cancel()
  wait for BURN_DRIVE_IDLE
  burn_drive_release()

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 :)

Thomas