[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to get a new palo source package into unstable?



Hi,

it is to early for a new description.
I have lots of questions after reading
http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/tree/lib/common.h

- Will there be a binary template for the first sectors
  of the ISO image into which the struct firstblock shall
  patched ?

- Shall xorriso allow kern_sz = 0 or rd_sz = 0 ?

- Increment PALOHDRVERSION to 5 ?

- What to write into cmdline_old ?

- How to determine the uncompressed kernel sizes ?
  kern32_native_sz , kern64_native_sz

- What value to write into flags ?

- How to determine the value of ipl_entry ?

- What block ranges shall be claimed by how many partitions ?

- What sizes of cylinder and head would be appropriate ?
  (ISOLINUX x86 isohybrid prefers 64 heads/cyl, 32 sectors/head.)

- You mentioned a "checksum (required by bios)" but i cannot
  spot a trace of it.
  What checksum algorithm will be used ?


-------------------------------------------------------------
The questions stem from this discussing with myself:


> The "magic" number is the assembly-language branch needed to skip over the
>  rest of the structure.

To what address does it jump and how does the code get
there which shall be executed ?
Will the user submit to xorriso a kindof boot block template
which contains that code at some higher address ?
(ISO 9660 allows up to 32768 user defined bytes at the start
 of the filesystem.)


> * kern_sz = 0 or rd_sz = 0 means no kern or ramdisk respectively.

Shall xorriso allow such values ?


> #define PALOHDRVERSION 4

Shouldn't this become 5 now ?
Version 4 is already used in the ISOs of Debian 4 and 5.


> struct firstblock
> char cmdline_old[128]; /* OLD: Up to 127 bytes of text plus a \0 */

So this is not used any more and should be 0s ?


> unsigned char pad1[0xf0 - 8 - 9 * sizeof (int) - 128];

/Start nagging mode/

I understand this is a file format. But the reader has no means
to determine the writer's sizeof(int).
So one will have to fixate the size of the integers rather than
accommodating the file format to it.
How about using 4 here, and to declare all applicable variables
as int32_t resp. uint32_t ?

Do you really need the offsets as signed integers ?
xorriso will by default put the boot files at low block addresses
in the ISO. Nevertheless this can be influenced by the user.
Maybe there are valid reasons to put other files before the
boot files.
So xorriso has to test whether the resulting byte offsets exceed
the field size. Unsigned would double the chance that they fit.

/End nagging mode/


> int      kern32_native_sz; /* 32bit kernel: uncompressed file size */
> int      kern64_native_sz; /* 64bit kernel: uncompressed file size */

How do i determine these two values ?
Shall they be handed over by program options ?
Shall xorriso uncompress the images and count the bytes ?
(What compression algorithm is used ?)


> unsigned int flags;

Does this have a meaning already ?
Do we need to pass a value by a program option ?


> int ipl_entry;

How to compute this value ?


> struct partition part[4];

Argh. MBR-style partition entries. (I see it in part.h and shudder.)

What block ranges shall be claimed by those partitions ?
(0 to end of ISO image as partition 1 of type 0xf0, other
 three zero ?)

What sizes of cylinder and head would be appropriate ?
We have to assume them without knowing the device geometry
where the ISO image will end up.

(I wonder what happens if PC-BIOS encounters this thing
 which roughly looks like an MBR.)


> char cmdline[CMDLINELEN]; /* max 1023 bytes of text plus a \0 */

I assume that this is the new place for the command line.

-------------------------------------------------------------

Have a nice day :)

Thomas


Reply to: