On 10/14/2009 02:38 AM, David Cantrell wrote:
> On Tue, 13 Oct 2009, Steffen Maier wrote:
>> On 10/13/2009 10:42 PM, David Cantrell wrote:
>>> On Tue, 13 Oct 2009, Steffen Maier wrote:
>>>> On 10/13/2009 03:51 AM, David Cantrell wrote:
>>>>> Expand the DASDDevice class to hold the device bus ID and flags
>>>>> that are
>>>>> passed at boot time. Add udev functions to return the bus ID and flag
>>>>> values for DASD devices. When building the device tree, read the DASD
>>>>> information and pass that to the DASDDevice object.
>>>>> ---
>>>>> storage/devices.py | 9 ++++-----
>>>>> storage/devicetree.py | 10 ++++++++++
>>>>> storage/udev.py | 30 ++++++++++++++++++++++++++++++
>>>>> 3 files changed, 44 insertions(+), 5 deletions(-)
>>
>>>>> diff --git a/storage/devicetree.py b/storage/devicetree.py
>>>>> index d355804..cff7591 100644
>>>>> --- a/storage/devicetree.py
>>>>> +++ b/storage/devicetree.py
>>>>> @@ -1192,6 +1192,16 @@ class DeviceTree(object):
>>>>> kwargs["exists"] = True
>>>>> elif udev_device_is_dasd(info):
>>>>> diskType = DASDDevice
>>>>> + kwargs["busid"] = udev_device_get_dasd_bus_id(info)
>>>>> + kwargs["opts"] = {"ro": udev_device_get_dasd_flag(info,
>>>>> +
>>>>> "readonly"),
>>>>> + "diag": udev_device_get_dasd_flag(info,
>>>>> +
>>>>> "use_diag"),
>>>>> + "erplog":
>>>>> udev_device_get_dasd_flag(info,
>>>>> +
>>>>> "erplog"),
>>>>> + "failfast":
>>>>> udev_device_get_dasd_flag(info,
>>>>> +
>>>>> "failfast")
>>
>>>> Maybe we want to have a dict of sysfs attribute names along with the
>>>> default value for each attribute. If the read value from sysfs equals
>>>> the default value, we would not even emit this attribute and its value
>>>> to kwargs["opts"].
>>>
>>> Not interested in that. The default is already in sysfs and reading
>>> it and
>>> carrying it around doesn't hurt much. Storing defaults in anaconda
>>> means
>>> another place to maintain that information.
>>
>> In your previous code you had that defaults coded in the boolean values
>> (0 happens to be the default for our current set of attributes) and did
>> only emit the options if they were true, so why not continuing similar
>> behavior?
>
> Well, that was based on how the dasd= parameter worked. If the flag was
> not
> meant to be enabled for a DASD, you don't add it to the
> dasd=x.y.z(flag:flag:...) line.
>
>> Recently I was suggesting among our developers to blindly write out even
>> default configuration values to sysfs attributes. Our kernel maintainer
>> brought up a noteworthy case, where overwriting default values might be
>> counterproductive, and pursuaded me that it might not be a good idea: If
>> a default value gets changed in the kernel in order to transparently
>> provide performance improvements to the user and the user had already
>> configured such devices previous to the kernel change, then he could not
>> transparently exploit the performance improvements. Instead he would
>> have to know about that potential disadvantage and then manually tweak
>> the respective device configuration.
>
> I'm ok with that, but I don't think this logic should be in anaconda. The
> main problem I see is we'd have to know what the kernel defaults are in
> order
> to maintain the default values in the code. Unless the kernel is exposing
> that somewhere, there's no way that I know of get that information
> programatically.
I agree that it would be a nightmare to maintain the default values in
anaconda. Shortly after having sent my previous mail, I realized where
the problem here is and how this could work instead. The only place
where we could easily track which attributes have been overridden by the
user is at the UI. Currently this is the DASD question in linuxrc.s390.
In the future it would also be a "(de)activate DASD" dialog in advanced
storage of anaconda. For linuxrc.s390, every option that the user
specified would have to be remembered and then emitted for
dracutSetupString. For the new dialog, it could set DASDs online and
then easily display the default options for each DASD by reading from
sysfs. Since we would not have written to sysfs option, sysfs would
provide us with the default values. Hence there is already this way how
the kernel exposes default values to user space. For each dialog widget
the user had changed, we would write the values to sysfs and again
remember which attributes that were to emit them for dracutSetupString.
Unfortunately, this contradicts the currently designed passing of
attribute values by means of sysfs without any direct parameter passing
between UI and anaconda storage device backend.
That said, I don't mean to change design for the time being but only
state this for (future) reference.
> I like the idea now of collecting the sysfs attributes and storing the
> value
> read as string and then handing that off to dracut. dracut may be a more
> appropriate location to implement what you're talking about, but even then,
> it's still going to require knowledge of kernel defaults inside a userspace
> program unless the kernel exposes driver defaults somewhere at runtime.
Right, dracut might be more appropriate than anaconda but dracut knowing
default values would be kind of the same nightmare as in anaconda.
Steffen
Linux on System z Development
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Erich Baier
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
