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]

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 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.

- -- David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkrVHYIACgkQ5hsjjIy1VkkUaACgvuIVWumj9M+RQEssGV5KRQt5
+TMAoIauaN2iF7pNBvgCkKLB28okKRsL
=HND/
-----END PGP SIGNATURE-----

_______________________________________________
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