[Debburn-devel] schilyutils upload
Steve McIntyre
steve at einval.com
Wed Aug 12 14:57:49 UTC 2009
On Wed, Aug 12, 2009 at 04:25:54PM +0200, Thomas Schmitt wrote:
>Hi,
>
>Steve McIntyre wrote:
>> ... libburnnia and friends ...
>> I have some porting
>> work that I need to do to make that happen usefully (e.g. the code in
>> genisoimage to generate jigdo files),i
>
>I have read http://atterer.net/jigdo/ and
>man genisoimage, especially JIGDO NOTES.
>If i understand it right then the task
>of genisoimage is to read the -md5-list,
>and to generate -jigdo-jigdo and
>-jigdo-template along with the ISO image.
Yup, that's correct.
>> and I'm struggling to find the tuits.
>
>Our libburnia documentation or the one of
>jigdo ?
tuits -> "round tuits" -> "around to it" -> time.
Sorry, silly en_GB slang...
I can find what I need to do the job, it's just the time to dig into
it.
>For telling where to implement the jigdo
>features i would need some more info about
>the task of the ISO 9660 formatter with jigdo.
>- What goes in ?
>- What goes out and how is it computed ?
>- What side effects on the emerging ISO image ?
>- How is the relation to the pathspecs given as
> normal genisoimage arguments ?
The output jigdo file(s) are simply another representation of the
contents of the ISO image. The image itself is identical with/without
the jigdo generation options. The data is organised such that:
* contents of files that we know about (i.e. listed in the -md5-list)
are referenced by checksum in the .template file instead of being
included directly. The md5->filename lookup information is stored
in the .jigdo file.
* any other data that does not match known files is compressed and
stored directly in the .template file (e.g. filesystem headers,
directories, padding)
>From these two files and an archive of the files used, it's possible
to recreate the output ISO image very cheaply. For people downloading
Debian CDs and DVDs, it's a convenient way to potentially save on a
lot of bandwidth.
>The implementation candidates would be
>- libisofs
>- xorriso
>Within both we would have to identify the
>hooks where to attach jigdo functions to
>the existing code.
>Both are designed as collection of independent
>API functions. Nevertheless the image generation
>code of libisofs is quite complex. Best would
>be to perform all jigdo operations before
>the image stream gets produced.
I hooked into mkisofs/genisoimage by simply targetting all the places
that write to the output ISO image, and adding a parallel call to the
jigdo code there. Oh, and of course some startup and shutdown code
too. Not too difficult if the internals are clean and easy to follow
(as I hope)... :-)
>We do not support UDF yet. Would that be a problem ?
Not for me, no. I'm more interested in using/adding hfs hybrid code to
support Macs, frankly.
--
Steve McIntyre, Cambridge, UK. steve at einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
More information about the Debburn-devel
mailing list