[Libburn] structure.h

Derek Foreman manmower@signalmarketing.com
Wed, 14 Jan 2004 21:45:48 -0600 (CST)


On Wed, 14 Jan 2004, Laurent Sansonetti wrote:

> On Wed, 2004-01-14 at 03:56, Derek Foreman wrote:
> > On Tue, 13 Jan 2004, Laurent Sansonetti wrote:
> >
> > The problem is, some of the stuff in structure.h is only useful
> > internally, so if I export the whole mess and allow direct access to
> > those structures, if I want to add/remove a member later, I break
> > applications currently linked with the lib.
>
> Mmh I see your point.  What about creating new functions to wrap this:
>
> struct burn_session *
> burn_disc_get_sessions (struct burn_disc *disc, int *n_sessions);
>
> struct burn_track *
> burn_session_get_tracks (struct burn_disc *disc, int *n_tracks);
>
> struct burn_toc_entry *
> burn_track_get_entry (struct burn_disc *disc);
>
> etc... ?

Hmmm, close...

how about struct burn_track **burn_session_get_tracks(blah) instead,
because the pointers will be the same size no matter what I do to the
structs...

I've done this up in cvs, toc.c now compiles without any "internal"
include files.

(btw, burn_toc_entry is a special case because it's defined in the cd
standards, that's why I allow access to it directly)

> BTW, I tried libburn a few days ago with some friends and it seems that
> it can only recognize drives with 2.6.x Linux kernel releases (do not
> work with 2.4.x releases).   Is it a well known issue?

Uh oh.  It should work with both.  Is it just a file permissions issue?

If you can email me a strace of a 2.4.x run of test/devices, I can
probably find the problem.

> Cheers, and keep the good work!  The Ruby bindings are almost finished.

Cool, thanks. :)