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