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

[scdbackup at gmx.net]

Hi,

> Derek:
> location is a unique identifier, yes.  And it's a 1:1 mapping.

Ok. If the limited persistency of the .location addresses
is ensured then i think my current use of .location
conforms to the API.
("limited persistency" in the sense that the address
 remains stable over reboot but not over heavy sysadmin
 activities.)


> We could have a function to open a drive by location.

So my proposal is now:
  int burn_drive_scan_single(struct burn_drive_info **drive,
                             const char *location);

As stated previously i would prefer if the single-drive
function yields a result compatible to  burn_drive_scan().
This allows me to forget about the drive list restriction
in the further course of processing.


> (further, we could pass an array of these things to libburn to get our 
> drive info array?)

This array is equivalent to my original proposed whitelist.
My own tool needs only one or all drives. But GUI tools
might want to preselect some drives which they offer to their
user.
So i dropped that proposal mainly because i myself don't need
it. But if you want subsets of the global drive list then it
should pop up again.  


> I think the front end would be responsible for dealing with the HAL 
> database...

We need a convention about the addressing.

As said, i currently make twofold use of .location:
1) as unique persistent drive identifier
2) as hint for the sysadmin what to administer

The first purpose would only demand that .location holds
unique strings after full burn_drive_scan() and that those
strings can be reproduced as long as the system is not
altered.

The second purpose demands that the actual operating
system (or HAL ?) provides some tool to administer the
device depicted by the .location string .

I get the impression that both purposes should be split
into two members of burn_drive_info
1) .drive_id
2) .location
Currently both would have the same content. But as soon
as HAL or other abstractions are used, .drive_id is 
allowed to become any text (i plead for a single word)
while  .location  still should help the sysadmin to
find the system device object.

We can be lucky and all future hardware abstractions
will allow to have .drive_id and .location identical.
But a new member .drive_id is inexpensive and it
would allow to encapsulate future design decisions.

If .drive_id is to be introduced, then this should be 
done soon.


>> Blacklists and Whitelists".

It is well understood, Derek, that you do not object
because you don't like them but because you want to
keep libburn on its track.

But your above idea about an array of enabled drives is
1:1 equivalent to the whitelist. Just a different
function API.
The higher abstraction of a separately managed
whitelist (and possible blacklist) is desirable in my
eyes. It also frees you from the need to introduce
a new drive handling function. 
burn_drive_scan() would be all that's needed.

Additionally i have to stress that the whitelist approach
is _tested_ heavily, meanwhile. 


> Dana:
> In theory it could give us more information about a drive, like known
> bugs. "This drive can't do DAO even though it says it can" and such.
> 
> Is that up to us to parse or should we leave that up to the frontend
> though? I'm starting ot think maybe we shouldn't be touching libhal at
> all...

I understand libburn as a model of a set of drives
and the methods to handle them.
Therefore i would expect that libburn isolates me not
only from Orange Book and IDE but also from complicated
hardware abstractions.

Although it might become necessary in special situations to
negociate directly with the hardware abstraction i would
prefer if in normal situations libburn was able to provide
all necessary services.

Thus my proposal of a unique identifer .drive_id which would
allow to map the hardware structure into a simple list of
drive names (whatever names that are).

The use cases would be:

- ask libburn for the list
- choose one of the presented identifiers
- use that identifer to obtain the drive number
  (resp. the drive object within libburn).

and:

- obtain identifier from a stored configuration
- use that identifer to obtain the drive number


> Is there any advantage to sending us a HAL ID as opposed to
> the dev node listed by HAL?

There is a difference if there is a HAL ID but no dev node. :))

The specs of HAL let me shiver. It is a great idea but as
far as i read up to now it does not look very mature.
The elasticity has to be curbed more. There needs to be
a minimum information set that is guaranteed to exist.
I can hardly make use of an API of which the semantics
are so undefined.
The task to develop a unique mapping from a generic HAL
object to a .drive_id string might become quite demanding.

Well, i guess people smarter than me have already invested
their thoughts. Maybe i just missed the decisive point.


Currently i a trying to find out why the CVS version
of test/burniso does not work any more. I get the impression
that CVS-libburn itself is broken.


Have a nice day :)

Thomas