Re: How to get a new palo source package into unstable?
Hi,
> > - Will there be a binary template for the first sectors
> Is it needed?
The comment in lib/common.h says that it is assembly language
and skips to code. That code would have to stem from some template
file.
But as you stated later in your newest mail, this is not the case.
Another outdated comment in common.h is:
"This struct [firstblock] [...] must stay 256 bytes in length!"
> > - What block ranges shall be claimed by how many partitions ?
> The partition table is only relevant if the firstblock is on hard disc.
> Since you target a bootable CD image it's not relevant and leave it 0.
In the x86 world of ISOLINUX or GRUB2, the ISO images can be
copied onto hard disc (resp. USB stick) and boot from there too.
For that purpose, there are MBR, GPT, and/or Apple Partition Map
at the beginning of the images. (E.g in Debian amd64 ISO images.)
Would similar be possible for HP-PA ?
Would HP-PA boot via USB at all ? (The last PA-RISC i saw was
a HP 735 which quite surely had no USB besides its HIL.)
> "ipl" is the generic name.
genisoimage calls this obviously "bootloader".
Can we stay with option name -hppa-bootloader or shall i change
it to -hppa-ipl ?
> > > * kern_sz = 0 or rd_sz = 0 means no kern or ramdisk respectively.
> > Shall xorriso allow such values ?
> No, I think it should not allow that.
> We target a bootable install-image. For that kernel and ramdisk is needed,
> right?
It is improbable that more users of xorriso HP-PA boot features
arise . Nevertheless, xorriso should not restrict deliberately
what might make sense in special situations.
So if PALO will be able to handle missing kernels (by gracefully
not booting) it might be worth to allow it.
I leave it to you to prescribe these constraints:
- May one of the kernels be missing ?
- May the RAM disk file be missing ?
xorriso (resp. libisofs) will enforce what you decide.
(Currently it wants to see command line and all four files.
Else you get
libisofs: FAILURE : Incomplete HP-PA PALO boot parameters
)
> Give me a few days and I will actually test your code and send you
> necessary patches (if needed).
All my published HP-PA activities are in this changeset
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1111
You will have to adapt
libisofs/system_area.c:make_hppa_palo_sector()
to your new command line location and length limit.
In my local copy i already reduced the limit for file location
- if (adr64 > 0xffffffff) {
+ if (adr64 > 0x7fffffff) {
iso_msg_submit(t->image->id, ISO_HPPA_PALO_OFLOW, 0,
- "HP-PA PALO boot address exceeds 32 bit");
+ "HP-PA PALO boot address exceeds 2 GB");
The API call iso_image_set_hppa_palo() might get even more
parameters, depending on what you decide about
firstblock.flags,
firstblock.ipl_entry
firstblock.kern32_native_sz
firstblock.kern64_native_sz
We will have to define the final prototype before next release
of libisofs. Afterwards it will be immutable. (No release
date is planned so far.)
As for kern*_native_gz:
xorriso can be linked with libz and is then able to uncompress
gzipped file content. So if your gzip.c and inflate.c are
compatible to program gzip, then it would be possible to
count the uncompressed bytes.
Linking of libz happens automatically if libz runtime and its
developement header files are installed when GNU xorriso
gets compiled.
Automatic detection of compressed files should be possible too.
Question is, whether it is always desirable to write kern*_native_gz
if the kernel file is recognized as gzipped.
When all decisions are made, i plan to keep the genisoimage style
production of PALOHDRVERSION 4 and to add a new "System area type" 5
for PALOHDRVERSION 5.
(See libisofs/libisofs.h , function iso_write_opts_set_system_area(),
"options" bits 2 to 7.)
There will probably be a new -as mkisofs option "-hppa-header-version"
with default value 5.
Have a nice day :)
Thomas
Reply to: