[Libburn] Reading procedure

[Derek Foreman]

On Fri, 22 Oct 2004, Tiago Cogumbreiro wrote:

> On Fri, 2004-10-22 at 18:11, Todd Kulesza wrote:
>> Bryan Forbes wrote:
>>> One big problem I see is that there is no Joliet support in libisofs.
>>> If you know anything about that, I think it would be wise to hack on
>>> that.  What's the point of burning if you can't burn a good format? ;)
>>>
>>
>> I believe Windows NT/2000/XP and possibly 98 all support Rockridge
>> discs--why would we want to add Joliet?
>>
>> Todd
> I have a VMWare image of win98 and can test on a winxp, i will test
> rockridge formats. How broken is libisofs?

Current rumour is it doesn't support on the fly burning, but it works fine 
for writing image files.

> IMO we need a new release ASAP! We need motivation from the different
> contributers/developers and after a 0.3 release we might provide/feel
> that boost :)
>
> I think I can make TAO work. I've done it once. However I need to
> understand how everything works on libburn again, since I've forgotten
> :(

I think there are bits and pieces of TAO already in there, I think it 
really just needs a bug or two ironed out.

> It would be nice to add a Wiki of some sort or some official roadmap, so
> we can know what to work on. Reading the roadmap[1] Derek explained
> before.
>
> 0.3:
> 1. TAO support
> 2. integrate Stephane's speed-list patch in an exportable way
> 3. resolution to what appears to be a bug in libisofs's burn source
> functions that prevents on the fly creation of ISO images
>
> Can I have more detail on 2 and 3?

2: Stephane Ouellette (I know I spelt his name wrong, and I apologize, I 
can only hope that in time he will find it in his heart to forgive me) 
sent a patch that queries the list of drive speeds from a device.  It's in 
the archives somewhere.  This is a rather useful thing to have, I think, 
but it might not work for all drives, and it didn't do it in a way that I 
thought was clean to expose to a front end.

3: Forbsey says libisofs doesn't work.

> 0.4:
> 1. HAL for selecting drives instead of the fairly hackish stuff we have right now
> 2. multi session support
> 3. DVD burning
> 4. Reading Images
>
> Derek do we want HAL support? What for? Only for scanning the system
> drives? (I'm not saying we shouldn't)
> I have no knowledge on 2 and 3 whatsoever. However 4 would not be that
> hard to work on.

I think we want HAL, but I'm really not 100% sure.  I was given the 
impression that HAL was going to be the shiney new way to enumerate and 
access devices from userspace.

It would seem to me that HAL would provide the ability to blacklist 
drives.  Asking a drive what write modes it supports is a bit of a blunt 
instrument.  You just try to set up a write in each of the possible modes, 
and record whether the drive gave you an error or not.  Some drives wont 
generate errors even when they can't support a mode.

In fact, some drives do some very stupid things.

Also, fabricating host/unit/lun for devices that aren't really scsi has 
come up numerous times on lkml in a fairly bad light.  So we probably 
don't want to export that pseudo information to an app.

We need some sort of device enumeration, and if HAL wants to handle that, 
then that's fine with me.  but at least until HAL becomes widely adopted, 
libburn will also need its own enumeration method :)

Is HAL going to be the new way to query device properties?  write/read 
speeds, etc?

(If I've misunderstood what HAL is for, someone please let me know :)