Re: [Libcdio-devel] Distraction over Wikipedia topic, was Rock Ridge and libisofs/xorriso 'AL' extension

[Thomas Schmitt]

Hi,

me too: Apologies for being off topic here. :))

Natalia Portillo wrote (about the Wikipedia "original research" rule):
> Even then other problems would arise that you wouldn't be able to
> correct, and ignorance will spread.

Meanwhile i inserted a statement and a citation about SUSP field "ZF"
which marks zisofs compressed files in an ISO.
If this does not cause a reaction from the authorities then i will
cautiously widen the description of "AL" by Pete Batard.
(It is more or less a representation of xattr attributes, including
 a representation for ACLs.)


> the people
> with the best knowledge to correct the information is limited by two points:
> 
> 1.- The "independent research" policy that is precisely what made you
> the one who knows best about that issue in the world.

Yeah. I am tempted to tell this to the "WikiProject Computing",
which has its fat label on the Talk page of the Rock Ridge article.
Their idea of quality is too much oriented towards scholars and
academic research. The habits of IT about specifications and interfaces
do not fit into this model at all.


> 2.- The majority wins,

That's the general problem with democracy.
Like Linux it is just terrible with all alternatives being even worse.

Nevertheless, i as single expert can fight off a whole crowd of
wannabee experts by simply pointing out that my knowledge works
in a program which is used by the majority of Linux distros for making
their installation ISOs. (I still have to conquer RedHat and SuSE.)


> > So here I am being the engineer that cracked "independently" a
> > filesystem whose only knowledge about it before I did were the original
> > developers (and they lost their documentation :p)

I was able to annoy H. Peter Anvin to checkread my zisofs specs.
The content was swept up from his code in Linux and mkzftree.
Those kernel geniuses should each have a historian at their side who
records what they do and forces them to explain.

As far as i understand kernel code, this would also help to catch
the most stupid mistakes. Like the false rumor about fuzzy CD ends
in Linux sr. It's two TAO lead-out blocks ! Read the specs ! Grrrr !
The only valid excuse is that the drive firmwares create confusion by
reacting differently on those lead-out blocks.
  https://www.spinics.net/lists/linux-scsi/msg94638.html


---------------------------------------------------------------------
Somewhat more on topic:

i wrote:
> > (One may also find MBR, GPT, Sun Disklabel, APM, MIPS Volume Header,
> > DEC Bootblock, PReP, CHRP, or HP-PA PALO inside ISO 9660 images.
> > I have a byte-level description in
> >   
> > https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt

> Do you refer in code or in documentation?

In libisofs it's code and documentation which i made before that code
was implemented. I do this to support my own copyright claim for my
code, because my underlying knowledge often stems from inspecting other
people's programs. The documentation mentions the sources of information
from which i learned. Like an academic would piece together an own work
from the works of others and maybe some own reasearch.


> 'bout MBR, GPT and APM inside ISO images that's already done, the rest
> are I'm right now on it, but for me ISO images present a problem:
> They represent a 2048 bytes/sector device, while all of that hacks are
> aligned to 512 bytes/sector.

The block size is quite unambigous  at boot time because the non-El-Torito
boot equipment in the x86 world is valid only when the ISO is presented on
a hard-disk-like device, e.g. an USB stick.
This device must have a block size of 512 bytes, or else at least the
MBR partition tables would be wrong.

But even El Torito, which is valid only when presented on optical media,
has a mix of 2048 and 512: The block addresses are for blocks of 2048
bytes. The image size fields of the El Torito catalog count blocks of
size 512 bytes. (That's due to the floppy emulation history of El Torito,
i guess.)

The non-x86 world (SUN, MIPS, DEC, HP, ...) sticks mostly to 512 bytes
per block.


> So I'm unsure if I should code misalignment handling in the "bootblocks"
> code or create a "MODE SELECT" to the disc image code like old CD drives
> had :/

I have difficulties to make the connection from "MODE SELECT", which i
know as SCSI command to prepare a burn run, and interpretation of
boot equipment.

But in general, all the boot equipment variants have well defined
block size meanings with their block address and block counter fields.
One only needs to know which kind of boot equipment is being read.
Then it's unambiguous on byte address level, regardless of the medium type.

Of course, when reading blocks from medium, then one needs to know the
block size of that medium and possibly make the necessary conversion
by dividing or multiplying by 4.


Have a nice day :)

Thomas