[Libburn] Re: Cancelling an ongoing burn. Is this dangerous ?

[Dana Jansens]

On 2/9/06, scdbackup at gmx.net <scdbackup at gmx.net> wrote:
> Plus the prototype of the single drive "scan" function, like
>
>   int burn_drive_scan_single(struct burn_drive_info **drive,
>                              char *deviceadr);
>
> I would implement it on top of a whitelist which is not
> a part of the public API. You will then be free to choose
> a different implementation as soon as you have some time
> for it. The whitelist technology is designed to be harmless.
> It is tested with about 200 successful burn runs, a similar
> number of separate blank runs, and about 50 runs where a
> full unrestricted drive scan was desired.

It was a goal for libburn to use the freedesktop device demon for
choosing a drive eventually (with legacy support though, I think as it
is now), and so we avoided using any /dev paths in the API. On this
basis I would be against adding this function as is. Some way to scan
a drive would be nice. Perhaps you should have to scan all drives, and
then you can rescan a drive that has been returned to you. It won't
find a new drive ever, you'd have to scan all drives for that. And
you'd have to watch out for drives disappearing.

Thoughts on this all Derek? Is using the freedesktop stuff still a
good idea? I'm rather out of the loop on how it has been progressing
and adopted. Would using /dev paths make the API dysfunctional or
non-backwards-compatible in the future?

Dana