Re: [PATCH 2/8] Modify dracutSetupData() methods to return lists of dicts.

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

 



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

On Sat, 10 Oct 2009, Steffen Maier wrote:

On 10/10/2009 12:27 AM, David Cantrell wrote:
Update all of the dracutSetupData() methods to return lists of dicts
containing kernel parameter information.  The KernelArguments.get()
method in booty will iterate over the list and create the kernel
parameter string based on the dict entries.

This I really like. It's generic and extending with additional
parameters in the future will be possible without much code change if any.

Thanks.

Structure of the data returned from dracutSetupData():

    [{'option': STRING, 'value': STRING},
     {'option': STRING, 'value': STRING},
     ...]

Up to here, I was assuming one would only need one dict having option
names as keys and each key had a value string:

{STRING: STRING, STRING: STRING, ...}
e.g.
{'use_diag': '0', 'readonly': '0', 'erplog': '0', 'failfast': '0'}

The dicts in the list must at least provide an 'option' key.  Value can
be None, in which case just the 'option' part is added to the kernel
args list.  If option and value both exist, you'll get option=value
written to the kernel arg list.

In the future, the dicts may contain a 'combine' boolean and a
'delimiter' string.  Explanation is in the docstrings for
dracutSetupData in storage/devices.py.

I don't like the mix of sysfs attributes and anaconda internal "flags"
in the same dict. That makes the sysfs attributes look verbose since you
need the 'option' and 'value' keys to separate parameters from the
flags. Maybe I'm just thinking too much C like, but I would have
expected something like this:

Well, the list of dicts really is entirely internal to anaconda anyway.  It's
data that's used to construct kernel boot parameters.  How we gather that data
inside anaconda may be different for each kind of device, but the list of
dicts is to form kernel boot parameters that dracut can then combine in to a
string.

The reason I chose a dict for each parameter was so I could add optional
things that control the kernel parameter string generation process in booty.

struct dracut_setup_data_element {
 struct map parameters;
 char *(*filter)(char *input); /* signature just placeholder */
 char *delimiter;
 char combine:1;
};

However, with what I wrote in the reply to the patch intro mail, we
might not even need filter, delimiter, and combine.

Right.

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

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

iEYEARECAAYFAkrP22oACgkQ5hsjjIy1VkmfTgCg21TmHdVJYeaj+BtcjaQiUw1a
wt8AoJi+TbVKPtiBIqH6uxkL4oi7fTNU
=B9NL
-----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