Re: [PATCH 2/3] Collect DASD kernel parameter information during device tree scan (#526354).

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

 



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?

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.

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

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux