[Libburn] List of open decisions about my change proposals

[Derek Foreman]

On Tue, 14 Feb 2006, scdbackup at gmx.net wrote:

> Hi,
>
> i have reviewed our recent discussion about my patch proposals
> and made a list of things to be decided.
> The motivations are discussed enough, i believe.
>
> Five to seven bits. That's what is needed for now.
>
> - Type for source sizes (or byte counts in general) :
>
>  --- choose one of: --------------------------------------------
>  [X] off_t    with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
>  [ ] int64_t  with the demand to use a modern compiler
>               (my current SuSE Linux gcc 3.3.1 would do)
>
>
> - Relation of burn_source, burn_source_file and the
>  upcoming (fd,size)-Addon :
>
>  --- choose one of: --------------------------------------------
>  [X] fd source constitutes a new source class
>  [ ] fd source will be united with file source
>      --- in this case choose one of: ---------------------------
>      [ ] burn_file_source_new() and burn_fd_source_new()
>          coexist without calling each other
>      [ ] burn_file_source_new() opens fds and then calls
>          burn_fd_source_new(int fd1, int fd2, type_to_come size1)
>          where size1 == 0 causes size determination by fstat(fd1)
>
>  --- choose one of: --------------------------------------------
>  [ ] fixed_size applies to all burn_sources
>  [X] fixed size applies only to fd (eventually united with file)
>
>
> - Meaning of burn_drive_info.location now and in future :
>
>  --- choose one of: --------------------------------------------
>  [ ] .location will stay unique under all circumstances eventually
>      at the risk of losing the capability to direct the sysadmin
>      to the system management object of the drive.
>  [ ] .location will be a system management hint. A new member
>      .drive_id takes over the task of uniquely and persistently
>      identifying a drive.
>
>
> - Method of obtaining the scan information of only a single
>  drive without risking to touch any others :
>
>  --- choose one of: --------------------------------------------
>  [ ] somebody found a better proposal about how to tackle the
>      sticky drive problem but kept the solution secret up to now.
>  [ ] a new call is offered as alternative to burn_drive_scan():
>      int burn_drive_scan_single(struct burn_drive_info *drives[],
>                                 const char *id);
>      --- in this case choose one of: ---------------------------
>      [ ] The new call gets implemented on top of the whitelist
>          which has to be queried in the existing and future drive
>          enumeration functions. For details see:
>        http://lists.freedesktop.org/archives/libburn/2006-February/000371.html
>      [ ] The new call gets implemented independently of
>          burn_drive_scan() by circumventing existing enumeration
>          and addressing the drive directly. That would probably
>          mean to move the code from inside the loops of sg_enumerate()
>          and ata_enumerate() into separate functions sg_enum_single()
>          ata_enum_single(). Those get called by sg_enumerate(),
>          ata_enumerate() and burn_drive_scan_single().
>          burn_drive_scan_single() has to learn how to distinguish
>          between /dev/hdc , /dev/sg1 and future drive id types.
>
>
> ------------------------------------------------------------
>
> It seems that  burn_source_file.subfd  is not associated
> with any size determination, currently. I could not spot
> a function which would fstat that file descriptor.
> Derek, could you point me to an explanation for this sub thing
> in general ? In what use cases does it apply ?

off_t
fd source is a new source
fixed size only applies to fd

still undecided on the other two, I'm afraid...

subs are for "subcodes", there should always be exactly the same number of 
subcode packets as there are data packets, so the size of that can be 
determined by the size of the data.

You'll only see them when creating or copying truly bizarre discs.