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

Re: [master] & [f12-branch] dracutSetupString changes

On 10/10/2009 12:27 AM, David Cantrell wrote:
> how to write a kernel parameter for themselves.  The catch with dasd is
> that all of those parameters need to be combined in to a single dasd=
> parameter.

This is true for the dasd= parameter of the dasd_mod device driver
module. However, I'd like us to be aware, that it is just the current
simple dracut implementation which exposes the same syntax and hence
catch to anaconda. In general, this doesn't have to be. Dracut could
activate each DASD by itself just like linuxrc.s390 now does -- and like
dracut does for zFCP LUNs. That would require a little more code in
dracut since it could then no longer just pass the parameters string
untouched to the module by means of writing it to modprobe.conf. I'm
starting to think we should really discuss this with Harald.

> I've tried to keep the code as generic and flexible as possible.  The
> list of dicts returned by dracutSetupData:
>     Each kernel parameter (e.g., 'acpi=off') is a dict.  A dracutSetupData
>     method can return multiple kernel parameters, hence the list of dicts.

This, I only understood when I saw your sketch in patch 2/8. More
comments on the dicts in this other mail.

> Another catch with DASD is the need for *all* DASD bus IDs to be included
> in the dasd= parameter, regardless of whether or not they are used by the
> root device.

This is not because of DASD but because there is currently no initscript
that can activate non-root DASDs on boot. That could be repaired and I
think that would be the right solution now that you follow the clean
path for dracutSetupData with DASD in anaconda (instead of my proposed
one-string fits all quick hack).

> If you don't include them all, the administrator will have
> to bring them up manually.  To get around this problem, I added a property
> called forceDracut in storage/devices.py.  It's False for everything
> except DASDDevice.  Set it to True for force inclusion of dracutSetupData
> even if the device isn't used by the root device.

Jumping through hoops in anaconda to abuse dracut to activate all DASDs
seems wrong to me. We should really have an initscript for activating
all non-root DASDs and have anaconda tell dracut to only activate the
root devices. Isn't dracut supposed to only bring up the root fs?

(There will only be more than one root DASD, if parallel access volume
(PAV) is used, of which I don't know if that is supported of anaconda
and if it is even needed for installation since it is a performance
feature for e.g. data disks and I don't expect the root disk to be under
heavy load during installation and afterwards. Without PAV, we only have
exactly one root DASD to tell dracut.)

> Specific to DASD:  During the 'Finding devices...' step in anaconda is when
> the kernel parameter information is collected.  Values are read directly
> from sysfs.  While we don't expose any method in anaconda for changing these
> settings now, users could theoretically change things using a %pre script in
> a kickstart file and this code would still pick up the user's settings.  In

I really like this approach.

> the future I hope we can add an overwhelming and super confusing screen to
> let people configure the DASD parameters.

Let's just come up with an easy to use and nice small dialog. I have
ideas and a glade mockup already. However, the mockup without code that
fills in at least some example data is not very meaningful right now.
Same thing goes for activation and deactivation(yes I'm serious here) of
zFCP LUNs. But that is future work and I don't intend to formulate any
expectations here.

> Also, kickstart methods for
> changing those settings might be helpful.  I don't know.  But at least we

Considering the DASD= option of parm/conf file as a legacy hack,
kickstart methods for activating DASDs to install to would indeed be
helpful. It's implemented for zFCP LUNs already.

>     * DASD value filtering method.

We can get aroung the whole combination and filtering, if we go away
from the single (legacy) module string. In the light of trying to solve
this whole thing right, doing away with the legacy string seems like the
consequence to me. However, we cannot decide on this ourselves.

>     * Kernel parameter ordering.  Does this ever matter?

I cannot think of any example where it would matter right now.

>     * DASD global options such as nopav and nofcx, but that's a question
>       for IBM.  And by IBM, I mean Steffen.

That just cannot be me. Seriously, probably we don't need them. But then
again it would be nice if we could hand them over to dracut so they can
be effective when the DASD driver module gets loaded in initramfs. That
is the only way I know of to pass these options to the module. There is
no sysfs interface to do that later on dynamically.

>     * Another one for IBM:  Do we ever care about the autodetect or
>       probeonly dasd parameters?  My guess is no.

No, we don't care. In fact, we do not even want to have them available
for the user. Probeonly is only useful for device driver debugging.
Autodetect is evil and linuxrc has always correctly recommended not to
use it. Using autodetect, you don't know what disks get activated with
what options and in an LPAR with four thousand disks you do not want
them all activated because of memory usage (this multiplies by the
number of virtual machines and then it starts to really hurt!), sensing
time and user space deamons getting hickups with that many devices, and
also because of security issues (you don't want your z/OS operator to
discover that Linux touched and modified some disk it must not).


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

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