Lucius, Leland wrote:
That might be too short though as it wouldn't be easy to remember. Then I
thought, use the full 8 characters of the zipl.conf section name, but that
seemd like a waste. So, you're suggestion of 4 might very well be a good
middle of the road.
From the way other operating systems use it, I expected we had only 4 bytes?
A new value would have to be added to zipl.conf so the user could specify a
"LABEL" that would be used for the LOADPARM.
I find the entire zipl.conf thing very unpleasant in how it handles overrides
of the values in the config file. Would you want to rewrite all these entries
each time you update one kernel, or what? I suppose there is an advantage if
you make sure that all entries are still pointing to files that are still on
disk, but otoh this means that saving a new 'slot' for testing could affect
the kernel you run now.
How about four arrays: kernels, initrd, initrd2, command lines.
The 4 bytes of the loadparm could give the index in each of these. The reason
is that I suspect many will only change one at a time.
If this is not easy enough to remember you could have a table with names as well.
Another thing I couldn't decide on was what should happen if someone entered
a LOADPARM that wasn't valid. Disabled wait or use whatever was coded in
the "defaultboot" section? The latter could be very dangerous...
Disabled wait I think. The default applies to when you don't use loadparm.
I was wondering if you have enough system console up then to dump the list
of valid values.
PS Unless things changed recently, the LOADPARM is not documented afaik. This
used to be the objection of folks in Boeblingen against using it.
