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

[Natalia Portillo]

Hi,

The MODE SELECT is that basically you can change "sector size" on
several SCSI devices. On most hard disks it requires a reformat (NetApp
uses 520 bytes/sector afaik), but on early SCSI CD-ROM drives (up to
6x?) it supported changing the sector size to 512 and did the block cut
on firmware.

The 2x drive made by Sony and used in Sun computers and the Apple CD300
drive support this command, as well as having a jumper to choose power
up default (so you would need to MODE SELECT a 2048 bytes sector),
because their firmwares where hardwired to 512 bytes/sector.

I also have some Yamaha drives with that jumper.

Later drives omit the jumper and only support the command (that later
firmware uses), and even later drives support neither.

If you just put a SCSI DVD-ROM drive on a SparcStation 5, you cannot
boot :/.

'bout SGI and POWER computers, dunno, probably they did the same? I
think SGI EFS CDs indeed do.

So there's the question, anything that emulates an ISO with those boot
sectors, should suppor the "MODE SELECT" command somehow or expect the
applications it is feeding to do the sector cutting.

Regards,
Natalia Portillo

On 31/07/17 09:08, Thomas Schmitt wrote:
> 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
> 
>