On 11/18/2009 04:48 AM, Mark Hamzy wrote:
> Steffen Maier <maier@xxxxxxxxxxxxxxxxxx> wrote on 11/17/2009 09:18:42 PM:
>
>>>> function doreboot()
>>>> {
>>>> + if [ -e "/sys/firmware/reipl" ]; then
>>>> + read REIPL_TYPE < /sys/firmware/reipl/reipl_type
>>>> + echo "reipl_type=$REIPL_TYPE"
>>>> + pushd /sys/firmware/reipl/$REIPL_TYPE >/dev/null 2>&1
>> I see two problems with the informative code. First, anaconda supports
>> the two reipl types ccw for DASD and fcp for zFCP. The kernel interface
>> also supports other stuff such as nss (named saved segments). I think we
>> should only descend into the reipl type specific subdirectory and get
>> additional information for the two types anaconda supports because
>> anaconda does not know anything about the other types and how to
>> interpret their information. Which is fine, BTW, since those types are
>> not needed for installation.
>
> While the kernel interface supports other types, anaconda only sets one
> of the two. Which would make this code safe, right? It also is simpler:
> by keeping tests and specialized code out of the picture.
I considered this informational output to also serve problem
determination should anything not work as expected with reipl support in
anaconda. Just like the case we had in the corresponding bug here. In
the general case, any binary value could be read from some sysfs attributes.
>>>> + for i in *; do
>>>> + echo "$i=`cat $i`"
>> I'm not sure, if all sysfs attributes will always contain printable
>> ASCII text. I wouldn't want any potential binary data misconfigure the
>> console. Maybe a hexdump (e.g. od -xa) of the attributes' content would
>> make this safer?
>
> Yeah, we could change the `cat` to `od -xa`. Since the reIPL code only
> ever wrote ASCII data, I thought that's what it would only contain. And,
> if some other reIPL value were ever set, then showing safe informational,
> data on where it is rebooting into would be harmless what ever it
> contained.
Currently we write or reset a certain set of syfs attributes depending
on the reipl type. In the past, we had the case that new sysfs
attributes were added. Of such new ones, we would not know about their
content representation. Hence I would assume the worst case and
therefore make this "debug" output safe for all possible cases and not
just the good ones, where we wouldn't need the output since reipl just
works as expected.
For those attributes we already know and are sure that they contain
printable ASCII text, we may make an exception and print them directly.
But that would require distinguishing between known and unknown attributes.
Steffen
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
