I'm gzipping the patch and attaching it because the list manager keeps telling me that the size is too large. It is, but, well, that's how it came from IBM.
If I don't hear anything from people after a few days, I will take it that people are ok with this patch going in to rawhide. It's basically just a big rewrite to linuxrc.s390. There is also a new helper script for linuxrc.s390 that scans for devices on the system. And a one line patch to mk-images to make sure the new helper script is installed.
Here's the text of the commit message:
INTRODUCTION
After booting the installation environment on System z, there are no local storage devices such as a CD/DVD drive available to install RHEL from. Hence, only installation from network sources is possible, which requires an initial setup of a network device to reach such an installation source.
Due to the possibly large number of hardware network devices (hundreds) and the way they are configured in the hardware setup, Linux does not automatically detect and allocate all available network devices. There is need for a dialog from which the user can choose a sensible device configuration.
The least common multiple of console devices on System z is limited in functionality -- it only supports line mode. The initial network setup also provides the ability for users to login over the network from a curses capable text terminal, to provide an X window display, or to use VNC in order to continue installation.
DOWNSIDES OF CURRENT LINUXRC.S390
The initial network setup was done with a simple error-prone dialog without any possibility for the user to correct wrong input. On getting stuck, the only option for the user was a reboot, which of course means that he had to manually enter values all over again.
The user was asked various questions and had to know exactly what answers to provide for a successful network setup. Linuxrc.s390 provided no guidance or support to simplify the choice of correct answers for the user.
Configuration happened after the user had answered all questions which could lead to situations where configuration failed due to an earlier incorrect answer the user was not informed about.
User feedback has shown, that these downsides can be an obstacle for a successful installation of RHEL on System z.
IMPROVEMENTS OF NEW LINUXRC.S390
- dialog allows the user to correct single answers - dialog allows to restart configuration, providing previous answers as default values - dialog provides a sub shell for problem determination - cut-down question text prevents frequent scrolling on line mode terminal - explaining help text is shown for each question on user demand - automated decision which questions the user has to answer - semi-automatic configuration of network devices by providing a selection list of possible hardware configurations - manual configuration remains possible as before - sensible default answers are provided where possible - superfluous questions (NETWORK, BROADCAST) have been removed - answers by the user are strictly checked for syntax and semantics - whenever possible, each answer is used to do a configuration step and provide timely feedback to the user in case of an error - user transparent support of System z device blacklist (cio_ignore) for short boot times on systems with many (thousands) devices - basic support for installation from FCP-attached CD/DVD drive (our version of linuxrc.s390 is based on rhel5.3-snap1-20081029) - basic support for installation over IPv6 (full functionality would require further support in loader) - prints answers in a format which can directly be used for parm/conf file (as a complement to /root/anaconda-ks.cfg) - may serve as a specification on how to configure network devices on System z outside of an installer, e.g. in init scripts or configuration tools such as system-config-network
Otherwise, our version is fully compatible with the current version including the processing of parm/conf files. We made sure that existing parm/conf files from users are processed with the same outcome as previously. Also the interactive mode asks the user questions in the same order as before, so users do not have to adapt to a completely new structure of the initial network configuration.
Patch from Steffen Maier MAIER@de.ibm.com.
On Dec 5, 2008, at 4:00 PM, David Cantrell wrote:
I'm gzipping the patch and attaching it because the list manager keeps telling me that the size is too large. It is, but, well, that's how it came from IBM.
If I don't hear anything from people after a few days, I will take it that people are ok with this patch going in to rawhide. It's basically just a big rewrite to linuxrc.s390. There is also a new helper script for linuxrc.s390 that scans for devices on the system. And a one line patch to mk-images to make sure the new helper script is installed.
So, some comments from trying to go through and at least look for obvious problems/things to fix. Some of these may only be rawhide applicable and given that the patch was against the RHEL5 codebase, they may not be (easily) doable there
* A lot of checking for things like a 2.6 kernel. There's _always_ going to be at least a 2.6 kernel and such checks just needlessly complicate the script, making it that much harder to see what's really going on * Are udev and friends getting installed into the s390 initrd right now? * Some of the stuff in lsznet makes me think that modules should be getting auto-loaded by udev given the existence of modaliases and matching against things in /sys/bus/ccw * Didn't we stop allowing telnetd and switch to only sshd for logging into the install environment on s390 or am I just imagining things that I wish we had done? :) * Manual mknods shouldn't ever need to be present; udev should be creating device nodes * modprobe instead of insmod if modules have to be manually loaded so that at least dependent modules can be auto-loaded. This also lets us kill the $LO hack * There is code duplicated between the linuxrc and lsznet (see, eg, the declaration of $CU) and there's already divergence between the two * cardtype2cleartext() is the sort of thing which gets out of date and then becomes critical must fix bugs... if this information is important, it probably should be something we can query either with modinfo on a module or having the kernel tell it to us directly * Aren't we now doing udev rules for persistent device naming rather than modprobe.conf aliases? * Why are they disabling ipv6 autoconf? * Some of the helptext (helptext_nettype() is the one I'm seeing right now) is concerning. If something isn't supported, then we shouldn't support it. If the code is there, it's going to be considered supported * Also, given that these values have changed at least somewhat over time, if there's going to be help text, there needs to be some commitment for keeping it updated * Translators are going to hate a lot of the text. And given that this is being shown on the line mode terminal, how many translations can really be displayed? * Is there a reason if your IPL device is FCP that you wouldn't be doing a CD install? Shouldn't we default to detecting the CD like we do on other arches here unless you've passed 'askmethod' * Checking bash versions is also silly
Okay, now that my eyes are bleeding, I'm going to be done for now. The mix of new functionality, reformatting and changing the way things work makes this essentially unreviewable for correctness so I wasn't really able to address anything there :/
Jeremy
Hi Jeremy,
sorry for taking so long to respond. I was out of the office for a while. First of all, thanks a lot for your thorough review.
On 12/07/2008 04:56 PM, Jeremy Katz wrote:
On Dec 5, 2008, at 4:00 PM, David Cantrell wrote:
If I don't hear anything from people after a few days, I will take it that people are ok with this patch going in to rawhide.
That would be great, David.
And a one line patch to mk-images to make sure the new helper script is installed.
Maybe we also need to change a few more little things in the image building process to account for?:
# prerequisites of this script to run inside RHEL5.2 installer initrd: # - copy udevsettle and udevd to initrd # - create /etc/udev/udev.conf with at least one comment line as content
So, some comments from trying to go through and at least look for obvious problems/things to fix. Some of these may only be rawhide applicable and given that the patch was against the RHEL5 codebase, they may not be (easily) doable there
- A lot of checking for things like a 2.6 kernel. There's _always_
going to be at least a 2.6 kernel and such checks just needlessly complicate the script, making it that much harder to see what's really going on
I suspect you mean the two places in linuxrc where we check for at least Linux 2.6.26 which is when IPv6 support for HiperSockets in layer 3 mode went upstream. In other words this is not about being a 2.6 kernel (we already assume that anyway), it is about a certain sub-version. The reason why I put this check in was to make my code base as independent as possible from a specific RHEL release. In fact I put the checks in hoping that (almost) no changes would be necessary for running under RHEL6 as opposed to my development environment under RHEL5.2.
Lsznet raw was developed as a distro-independent tool which should work on a multitude of releases. Therefore, we check for some basic requirements. Does that make sense?
- Are udev and friends getting installed into the s390 initrd right now?
Just a minimum base consisting of udevd and udevsettle just for calling the latter as we potentially dynamically "add" (potentially lots of, i.e. thousands of) devices by dynamically freeing them from the device ignore list cio_ignore. Since this may take quite some time we do not know upfront, we decided to use udevsettle instead of a bogus constant sleep hoping all devices would have been sensed until we wake up and continue and try to use them. There is really not more than udevd and udevsettle, there are no config file (at least no content) and no rule files.
- Some of the stuff in lsznet makes me think that modules should be
getting auto-loaded by udev given the existence of modaliases and matching against things in /sys/bus/ccw
Lsznet does not load any kernel modules at all. It relies on the caller to setup the environment and does auto-sensing based on the given environment. In case you were referring to the arrays related to CU type/model: They are there for mapping the values in sysfs to user-friendly strings that appear in the generated table of possible network hardware configurations. Since they contain more information than what is in modalias, alas, they cannot all be automatically extracted from the kernel modules. E.g. cardtype, devname, and groupchannels cannot be deduced automatically.
With regard to linuxrc.s390, the way kernel modules are treated -- namely explicitly loaded including dependencies -- has been taken from the existing linxurc.s390 in order to introduce as few as possible changes. Also, trying to switch to auto-loading using udev would at least for the network types LCS and CTC which are based on cu3088 not be straight forward. The cu3088 module contains the modaliases but the corresponding driver modules (lcs/ctc) need to be loaded as well, see, e.g. RHIT 116546.
- Didn't we stop allowing telnetd and switch to only sshd for logging
into the install environment on s390 or am I just imagining things that I wish we had done? :)
Hm, telnetd does not get started. However, the strings that I took from the old linuxrc.s390 still mention telnetd. I'm open to fix this by removing the occurences of telnetd in the strings, if someone more knowledgeable than me confirms that telnetd really has been abandoned from the s390 installer initrd.
- Manual mknods shouldn't ever need to be present; udev should be
creating device nodes
I would fully agree, if we used a full-fledged udev environment. But as stated above it is only there to wait for device sensing. I even start udevd very late, when (according to a running udevmonitor in my test environment) all udev events concerning non-s390-devices have already vanished. As for now, this code is just what has been in linuxrc.s390 before we touched it. Introducing full udev just for linuxrc.s390 just did not seem worth it. What do you think?
- modprobe instead of insmod if modules have to be manually loaded so
that at least dependent modules can be auto-loaded. This also lets us kill the $LO hack
I don't know why this $LO thing is there, I just kept it from the existing linuxrc.s390. In fact, insmod and friends come from busybox which is why it finds, extracts, and loads the modules even though they reside in a modules.cgz. Since I did not understand the moddep magic of the busybox kernel module tools, I did not touch the explicit loading of dependencies. (And again there would be the LCS/CTC speciality mentioned above.)
- There is code duplicated between the linuxrc and lsznet (see, eg, the
declaration of $CU) and there's already divergence between the two
Wow, I'm impressed by the detail of your findings. The divergence is intentional. Lsznet was developed as a generic tool sensing all types of network adaptors independent of a use case such as in an installer environment. However, linuxrc.s390 is only interested in the supported ones, i.e. qeth, lcs (and the deprecated ctc and iucv) all with TCP/IP. With some magic we could put them in a common code base, but I refrained from doing so because it would have generated yet another (small) file both lsznet and linuxrc depend on.
- cardtype2cleartext() is the sort of thing which gets out of date and
then becomes critical must fix bugs... if this information is important, it probably should be something we can query either with modinfo on a module or having the kernel tell it to us directly
The output of cardtype2cleartext is for information presented to the user on the screen. Nothing more, nothing less. It is not used for any program logic. I don't think we can query it automatically such as using modinfo since the sysfs values only become meaningful after establishing a ccwgroup and setting the group device online, since only then the device driver gets this information from the adaptor; in other words, the values are dynamic. Sure, the device driver could provide user-friendly strings in the sysfs attribute. However, this would require changing the existing value other software may already depend on and would break on changing the strings. That's why I'm convinced that the values won't be changed often if at all and we should be safe with a static mapping table. If a new sysfs value should appear in the future, our code will inform the user and we may easily fix it.
- Aren't we now doing udev rules for persistent device naming rather
than modprobe.conf aliases?
Sorry, I don't know about that. Would that be a Rawhide/RHEL6 thing? If so, could you please point me to some more information so I can make the script more Rawhide compliant?
- Why are they disabling ipv6 autoconf?
Disclaimer: IPv6 support is not (fully) functional. The part in linuxrc should be complete but support in loader is missing for transferring the configuration over to stage2.
As far as I understood linuxrc, it only supports manual configuration of IPv4, i.e. no DHCP or other fancy stuff. So I coded IPv6 support the same way. Am I mistaken that we either ask the user for IP address and the like or user autoconfiguration?
- Some of the helptext (helptext_nettype() is the one I'm seeing right
now) is concerning. If something isn't supported, then we shouldn't support it. If the code is there, it's going to be considered supported
At least for RHEL5 I was told, that the code including drivers are still there since there might be customers needing those things even though they might not be officially supported by RHEL. Since we on System z are very careful not breaking any potentially old environment I made sure the code for CTC and IUCV remains there and also benefits from the improved user interface. In fact it was in the existing linuxrc and I just transferred it over.
- Also, given that these values have changed at least somewhat over
time, if there's going to be help text, there needs to be some commitment for keeping it updated
I'm all for keeping them updated. One more comment: What we now call helptext was previously part of the question presented to the user. We split that in two, so we can ask the user in a one-liner (since screen real estate is precious on a 80x25 green screen not scrolling but flipping pages) and still provide the more self explaining "helptext" on request as it was there before. While having been at it, we updated the texts already to reflect current state.
- Translators are going to hate a lot of the text. And given that this
is being shown on the line mode terminal, how many translations can really be displayed?
AFAIK, the texts in linuxrc haven't had any translations so far even though they were already previously coded with the deprecated $"..." construct of the bash. From the top of my head, I wouldn't even come up with a solution when and where to select a language before linuxrc starts running. In a nutshell, I assumed there would only be English texts and as a non-native speaker I welcome any suggestions for improvement (hoping they still fit into one line ;)).
- Is there a reason if your IPL device is FCP that you wouldn't be doing
a CD install? Shouldn't we default to detecting the CD like we do on other arches here unless you've passed 'askmethod'
You're right, there might be a case where the user IPLs the install environment from an FCP device other than a CD/DVD drive, e.g. an FCP harddisk. Such case can even be used for debugging DVD install support in linuxrc without the need for a DVD drive. However, I guess this has not been deemed a valid use case for installation which is why there is not the "usual" CD detection. I have to think about the latter, if and how something like that would be possible on s390 and especially how that would be possible in the very limited linuxrc. In any case it is necessary to set the FCP adaptor online and add port and LUN before anything can be detected by means of SCSI device type. And that is exactly what is done right now, there is nothing more in linuxrc. While writing this, I realize that the detection of a CD/DVD drive is already done platform independent by the loader! We even verified this. If you IPL from FCP disk, loader won't let you select CD install, only if you IPL from FCP CD/DVD. And I think askmethod should just work. Ain't that nice? Sometimes s390 boggles my mind.
- Checking bash versions is also silly
As mentioned above, lsznet was designed independently as a generic distro-independent tool and I found many peculiarities with different bash versions. I found it more user-friendly to bail out early than to keep on running and producing errors all over since the necessary bash functionality is not there.
Okay, now that my eyes are bleeding, I'm going to be done for now.
I'm sorry. Hope you cured meanwhile. :)
The mix of new functionality, reformatting and changing the way things work makes this essentially unreviewable for correctness so I wasn't really able to address anything there :/
IMHO, you addressed a lot of valid points which I am thankful for. I tried to retain as much of the old code as possible but the new user interface and all the new checking which was missing before plus some rearranging for better maintenance made it virtually undiffable. :( For what it's worth, I spent a lot of effort making sure it behaves like the old linuxrc with regard to configuration outcome.
Sorry for the long reply. On System z things are sometimes quite special and I felt that thorough explanations are in order.
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
On Thu, 2009-01-01 at 01:27 +0100, Steffen Maier wrote:
On 12/07/2008 04:56 PM, Jeremy Katz wrote:
On Dec 5, 2008, at 4:00 PM, David Cantrell wrote: So, some comments from trying to go through and at least look for obvious problems/things to fix. Some of these may only be rawhide applicable and given that the patch was against the RHEL5 codebase, they may not be (easily) doable there
- A lot of checking for things like a 2.6 kernel. There's _always_
going to be at least a 2.6 kernel and such checks just needlessly complicate the script, making it that much harder to see what's really going on
I suspect you mean the two places in linuxrc where we check for at least Linux 2.6.26 which is when IPv6 support for HiperSockets in layer 3 mode went upstream. In other words this is not about being a 2.6 kernel (we already assume that anyway), it is about a certain sub-version. The reason why I put this check in was to make my code base as independent as possible from a specific RHEL release. In fact I put the checks in hoping that (almost) no changes would be necessary for running under RHEL6 as opposed to my development environment under RHEL5.2.
But a kernel version doesn't tell you those things -- distros backport kernel changes all the time. You have to instead check based on functionality being provided rather than assuming anything off of the kernel version.
Lsznet raw was developed as a distro-independent tool which should work on a multitude of releases. Therefore, we check for some basic requirements. Does that make sense?
It makes the code harder to maintain and if it's going to be in anaconda, then we really don't want those sorts of things.
- Are udev and friends getting installed into the s390 initrd right now?
Just a minimum base consisting of udevd and udevsettle just for calling the latter as we potentially dynamically "add" (potentially lots of, i.e. thousands of) devices by dynamically freeing them from the device ignore list cio_ignore. Since this may take quite some time we do not know upfront, we decided to use udevsettle instead of a bogus constant sleep hoping all devices would have been sensed until we wake up and continue and try to use them. There is really not more than udevd and udevsettle, there are no config file (at least no content) and no rule files.
My point was that I don't think that the scripts which generate the s390 initramfs (mk-images.s390) are pulling in the udev bits at the moment. Which means this won't work as-is.
- Some of the stuff in lsznet makes me think that modules should be
getting auto-loaded by udev given the existence of modaliases and matching against things in /sys/bus/ccw
Lsznet does not load any kernel modules at all. It relies on the caller to setup the environment and does auto-sensing based on the given environment. In case you were referring to the arrays related to CU type/model: They are there for mapping the values in sysfs to user-friendly strings that appear in the generated table of possible network hardware configurations. Since they contain more information than what is in modalias, alas, they cannot all be automatically extracted from the kernel modules. E.g. cardtype, devname, and groupchannels cannot be deduced automatically.
This information *really* needs to be provided from the kernel. Otherwise, we're going to be carrying duplicates of it in anaconda.
With regard to linuxrc.s390, the way kernel modules are treated -- namely explicitly loaded including dependencies -- has been taken from the existing linxurc.s390 in order to introduce as few as possible changes.
It's already a complete rewrite to the point that diff is useless. So ditch the cruft. Reviewing in between the cruft being kept to try to "minimize" changes just makes life more painful
Also, trying to switch to auto-loading using udev would at least for the network types LCS and CTC which are based on cu3088 not be straight forward. The cu3088 module contains the modaliases but the corresponding driver modules (lcs/ctc) need to be loaded as well, see, e.g. RHIT 116546.
Then the drivers need to be fixed. Period. As of rawhide, *ANYTHING* calling modprobe for something which would be considered a "driver" is a bug. And as we move towards an initramfs for the installed system which also depends on udev, etc it will become even more explicit.
- Manual mknods shouldn't ever need to be present; udev should be
creating device nodes
I would fully agree, if we used a full-fledged udev environment. But as stated above it is only there to wait for device sensing.
Since this is going to rawhide, we should have a more fully-fledged udev environment. So the cruft needs to go.
I even start udevd very late, when (according to a running udevmonitor in my test environment) all udev events concerning non-s390-devices have already vanished. As for now, this code is just what has been in linuxrc.s390 before we touched it. Introducing full udev just for linuxrc.s390 just did not seem worth it. What do you think?
rawhide has udev everywhere other than s390 right now I think ;-)
- modprobe instead of insmod if modules have to be manually loaded so
that at least dependent modules can be auto-loaded. This also lets us kill the $LO hack
I don't know why this $LO thing is there, I just kept it from the existing linuxrc.s390. In fact, insmod and friends come from busybox which is why it finds, extracts, and loads the modules even though they reside in a modules.cgz. Since I did not understand the moddep magic of the busybox kernel module tools, I did not touch the explicit loading of dependencies. (And again there would be the LCS/CTC speciality mentioned above.)
$LO comes from the switch from .o files to .ko files with kernel modules going from 2.4 -> 2.6. It's mindless noise that should really be dropped. Also, we really don't want to use busybox insmod, etc at this point -- we should just use the pieces from module-init-tools.
- There is code duplicated between the linuxrc and lsznet (see, eg, the
declaration of $CU) and there's already divergence between the two
Wow, I'm impressed by the detail of your findings. The divergence is intentional. Lsznet was developed as a generic tool sensing all types of network adaptors independent of a use case such as in an installer environment. However, linuxrc.s390 is only interested in the supported ones, i.e. qeth, lcs (and the deprecated ctc and iucv) all with TCP/IP. With some magic we could put them in a common code base, but I refrained from doing so because it would have generated yet another (small) file both lsznet and linuxrc depend on.
If both pieces are in anaconda, then we can depend on it. If something's not supported, then modules just shouldn't be built and detection should carry-on from there. It shouldn't be based on arbitrarily which pieces of the shell script are left out.
- cardtype2cleartext() is the sort of thing which gets out of date and
then becomes critical must fix bugs... if this information is important, it probably should be something we can query either with modinfo on a module or having the kernel tell it to us directly
The output of cardtype2cleartext is for information presented to the user on the screen. Nothing more, nothing less. It is not used for any program logic. I don't think we can query it automatically such as using modinfo since the sysfs values only become meaningful after establishing a ccwgroup and setting the group device online, since only then the device driver gets this information from the adaptor; in other words, the values are dynamic. Sure, the device driver could provide user-friendly strings in the sysfs attribute. However, this would require changing the existing value other software may already depend on and would break on changing the strings. That's why I'm convinced that the values won't be changed often if at all and we should be safe with a static mapping table. If a new sysfs value should appear in the future, our code will inform the user and we may easily fix it.
Then add a new sysfs value. You guys are the upstream of the kernel module -- I'd rather have the new bits depend on newer kernels than carrying around display information that's out of date. Because inevitably, things that are used for "information presentation" become the last minute, fire drill, oh my god the world is falling apart bugs. Every. Single. Time.
- Aren't we now doing udev rules for persistent device naming rather
than modprobe.conf aliases?
Sorry, I don't know about that. Would that be a Rawhide/RHEL6 thing? If so, could you please point me to some more information so I can make the script more Rawhide compliant?
It is rawhide, yes. See the various udev rule generation in anaconda's network.py as well as the stock persistent rules in udev upstream.
- Why are they disabling ipv6 autoconf?
Disclaimer: IPv6 support is not (fully) functional. The part in linuxrc should be complete but support in loader is missing for transferring the configuration over to stage2.
As far as I understood linuxrc, it only supports manual configuration of IPv4, i.e. no DHCP or other fancy stuff. So I coded IPv6 support the same way. Am I mistaken that we either ask the user for IP address and the like or user autoconfiguration?
We ask because the impression that has always been given is that there isn't support for dhcp, etc on the s390 net adapters. If there now is, then it'd be great to use it instead :)
- Some of the helptext (helptext_nettype() is the one I'm seeing right
now) is concerning. If something isn't supported, then we shouldn't support it. If the code is there, it's going to be considered supported
At least for RHEL5 I was told, that the code including drivers are still there since there might be customers needing those things even though they might not be officially supported by RHEL. Since we on System z are very careful not breaking any potentially old environment I made sure the code for CTC and IUCV remains there and also benefits from the improved user interface. In fact it was in the existing linuxrc and I just transferred it over.
But again, if we're pushing something to rawhide (which is what David said he was doing), then we _shouldn't put the code in_.
- Translators are going to hate a lot of the text. And given that this
is being shown on the line mode terminal, how many translations can really be displayed?
AFAIK, the texts in linuxrc haven't had any translations so far even though they were already previously coded with the deprecated $"..." construct of the bash. From the top of my head, I wouldn't even come up with a solution when and where to select a language before linuxrc starts running. In a nutshell, I assumed there would only be English texts and as a non-native speaker I welcome any suggestions for improvement (hoping they still fit into one line ;)).
If it's not going to be translated/shown translated, then it shouldn't be marked with $"...". Then it's not a problem :-)
- Checking bash versions is also silly
As mentioned above, lsznet was designed independently as a generic distro-independent tool and I found many peculiarities with different bash versions. I found it more user-friendly to bail out early than to keep on running and producing errors all over since the necessary bash functionality is not there.
Yeah, but if it's not being packaged separately and maintained entirely separately, then we can make assumptions. Note: if you want to maintain lsznet as an entirely separate thing that anaconda just sucks in, much like we do lots of other utilities, that's fine too. And then check bash versions all you want :-)
The mix of new functionality, reformatting and changing the way things work makes this essentially unreviewable for correctness so I wasn't really able to address anything there :/
IMHO, you addressed a lot of valid points which I am thankful for. I tried to retain as much of the old code as possible but the new user interface and all the new checking which was missing before plus some rearranging for better maintenance made it virtually undiffable. :( For what it's worth, I spent a lot of effort making sure it behaves like the old linuxrc with regard to configuration outcome.
Yeah, I think that given the rearranging, etc, there's an effort which could definitely be made to remove some of the "cruft" rather than just trying to keep the old to keep the old. Exhaustive testing is the only way correctness is really going to be able to be determined with that much change.
Sorry for the long reply. On System z things are sometimes quite special and I felt that thorough explanations are in order.
Yep, s390 is a strange beast. I hope that as we move forward in rawhide, we can get it to be a little bit less strange and special as we use all the "normal system stuff" in anaconda across all arches (eg, udev/hal/NetworkManager). And if those don't work for s390, we should focus on fixing them rather than working around that fact in anaconda code (+ then the real system).
Jeremy
On 01/05/2009 06:02 AM, Jeremy Katz wrote:
On Thu, 2009-01-01 at 01:27 +0100, Steffen Maier wrote:
On 12/07/2008 04:56 PM, Jeremy Katz wrote:
- A lot of checking for things like a 2.6 kernel. There's
_always_ going to be at least a 2.6 kernel and such checks just needlessly complicate the script, making it that much harder to see what's really going on
I suspect you mean the two places in linuxrc where we check for at least Linux 2.6.26 which is when IPv6 support for HiperSockets in layer 3 mode went upstream.
[snip]
But a kernel version doesn't tell you those things -- distros backport kernel changes all the time. You have to instead check based on functionality being provided rather than assuming anything off of the kernel version.
Alas, there is nothing to check for this functionality. Knowing that the functionality will be in the kernel, the user is now unconditionally allowed to make use of it.
Lsznet raw was developed as a distro-independent tool which should work on a multitude of releases. Therefore, we check for some basic requirements. Does that make sense?
It makes the code harder to maintain and if it's going to be in anaconda, then we really don't want those sorts of things.
Removed all distracting checks.
- Are udev and friends getting installed into the s390 initrd
right now?
Just a minimum base consisting of udevd and udevsettle just for calling
[snip]
My point was that I don't think that the scripts which generate the s390 initramfs (mk-images.s390) are pulling in the udev bits at the moment. Which means this won't work as-is.
Correct. As mentioned earlier, it's necessary to add some new stuff to mk-images.s390. The first comment after the license header in linuxrc.s390 lists the prerequisites.
- Some of the stuff in lsznet makes me think that modules should
be getting auto-loaded by udev given the existence of modaliases and matching against things in /sys/bus/ccw
[snip]
In case you were referring to the arrays related to CU type/model: They are there for mapping the values in sysfs to user-friendly strings that appear in the generated table of possible network hardware configurations. Since they contain more information than what is in modalias, alas, they cannot all be automatically extracted from the kernel modules. E.g. cardtype, devname, and groupchannels cannot be deduced automatically.
This information *really* needs to be provided from the kernel. Otherwise, we're going to be carrying duplicates of it in anaconda.
They are only duplicates insofar as this information is in the driver code, e.g. conditional branches. It is being discussed to add this information as driver-specific sysfs-attributes with static content. Since we don't expect this to make it for F11, I left the mapping arrays in the code. See also [1].
With regard to linuxrc.s390, the way kernel modules are treated -- namely explicitly loaded including dependencies -- has been taken from the existing linxurc.s390 in order to introduce as few as possible changes.
It's already a complete rewrite to the point that diff is useless. So ditch the cruft. Reviewing in between the cruft being kept to try to "minimize" changes just makes life more painful
Removed all kernel module handling (insmod/rmmod). Please be aware, that we now fully rely on automatic loading of (driver) modules, which may very well need some adaptations to the building of the initrd. See also [2].
Also, trying to switch to auto-loading using udev would at least for the network types LCS and CTC which are based on cu3088 not be straight forward.
[snip]
Then the drivers need to be fixed. Period. As of rawhide, *ANYTHING* calling modprobe for something which would be considered a "driver" is a bug.
I was told, our drivers have been fixed upstream. However, this most probably won't make it into F11, so I'm going to provide some udev rules that help automatically loading the necessary modules.
- Didn't we stop allowing telnetd and switch to only sshd for
logging into the install environment on s390
Removed the remaining text parts referring to telnetd which was already not activated any more.
- Manual mknods shouldn't ever need to be present; udev should be
creating device nodes
[snip]
Since this is going to rawhide, we should have a more fully-fledged udev environment. So the cruft needs to go.
Those manual mknods, that are in linuxrc.s390, are exactly the ones that are in the current init.c of rawhide.
I even start udevd very late
[snip]
rawhide has udev everywhere other than s390 right now I think ;-)
Now starting udevd at the same spot as current init.c does. However, this might require some more basic udev rules. See also [2].
- modprobe instead of insmod if modules have to be manually
loaded so that at least dependent modules can be auto-loaded. This also lets us kill the $LO hack
[snip]
existing linuxrc.s390. In fact, insmod and friends come from busybox
[snip]
$LO comes from the switch from .o files to .ko files with kernel modules going from 2.4 -> 2.6. It's mindless noise that should really be dropped. Also, we really don't want to use busybox insmod, etc at this point -- we should just use the pieces from module-init-tools.
Dropped the $LO stuff and any manual (un)loading of kernel modules completely.
Sorry for confusion with the busybox insmod. In fact, it is the loader which also acts as insmod and rmmod if called with that name. If this is still a problem, I'm fine with using module-init-tools instead. But then we need to add them to the installer initrd and also rework the way kernel modules are packaged in the initrd.
- There is code duplicated between the linuxrc and lsznet (see,
eg, the declaration of $CU) and there's already divergence between the two
[snip]
with TCP/IP. With some magic we could put them in a common code base, but I refrained from doing so because it would have generated yet another (small) file both lsznet and linuxrc depend on.
If both pieces are in anaconda, then we can depend on it.
Since the pieces need to be in anaconda for the time being (see also below), I've restructured it to share common code/data and depend on that common file controlunits.sh, which is small.
- cardtype2cleartext() is the sort of thing which gets out of
date and then becomes critical must fix bugs... if this information is
[snip]
The output of cardtype2cleartext is for information presented to the user on the screen.
[snip]
Then add a new sysfs value. You guys are the upstream of the kernel module
Since this is presentation information, opinions were that this is not exactly something for the kernel but rather for user space. For the time being I left it in the code. See also [1].
- Aren't we now doing udev rules for persistent device naming
rather than modprobe.conf aliases?
The modprobe.conf aliases are still in the current linuxrc.s390 of rawhide despite writing of 70-persistent-net.rules in network.py. If it is safe to remove the writing of aliases in linuxrc.s390, I'm happy to remove them.
- Why are they disabling ipv6 autoconf?
[snip]
As far as I understood linuxrc, it only supports manual configuration of IPv4, i.e. no DHCP or other fancy stuff.
[snip]
We ask because the impression that has always been given is that there isn't support for dhcp, etc on the s390 net adapters. If there now is, then it'd be great to use it instead :)
Just for completeness (we won't tackle dhcp support for the discussed code here): AFAIK at least for qeth devices, DHCP should work since support for layer 2 mode has been introduced. Independent of that, many users don't have DHCP in their mainframe environment.
- Some of the helptext (helptext_nettype() is the one I'm seeing
right now) is concerning. If something isn't supported, then we shouldn't support it. If the code is there, it's going to be considered supported
At least for RHEL5 I was told, that the code including drivers are still there since there might be customers needing those things
[snip]
But again, if we're pushing something to rawhide (which is what David said he was doing), then we _shouldn't put the code in_.
The code is needed for fedora on s390 development. Brad Hinson says CTC is a hard requirement for the s390 emulator hercules: https://bugzilla.redhat.com/show_bug.cgi?id=462973#c5
- Translators are going to hate a lot of the text.
[snip]
starts running. In a nutshell, I assumed there would only be English
[snip]
If it's not going to be translated/shown translated, then it shouldn't be marked with $"...". Then it's not a problem :-)
Removed gettext marks and just use quoted strings now.
- Checking bash versions is also silly
As mentioned above, lsznet was designed independently as a generic distro-independent tool
[snip]
Yeah, but if it's not being packaged separately and maintained entirely separately, then we can make assumptions.
We thought about bringing lsznet.raw into s390-tools since not just anaconda might take advantage of lsznet.raw, but this is not going to happen right now which is why we need to bring it into anaconda for the time being. I removed the checks for bash versions.
Yeah, I think that given the rearranging, etc, there's an effort which could definitely be made to remove some of the "cruft" rather than just trying to keep the old to keep the old.
Done.
I'll post the updated code for review in another e-mail.
[1] This is what parts of the user output currently look like. It contains a reasonable amount of information that allows the user to match this to whatever he has been told by his sysprog who configured the LPAR or VM guest.
NUM CARD CU CHPID TYPE DRIVER IF DEVICES 1 OSA (QDIO) 1731/01 76 OSD qeth eth 0.0.f5f0,0.0.f5f1,0.0.f5f2 2 HiperSocket 1731/05 87 IQD qeth hsi 0.0.f000,0.0.f001,0.0.f002 3 CTC adapter 3088/08 88 ctc ctc 0.0.f020,0.0.f021 4 escon channel 3088/1f 89 ctc ctc 0.0.f030,0.0.f031 5 ficon channel 3088/1e 8a ctc ctc 0.0.f040,0.0.f041 6 LCS p390 3088/01 8b lcs eth 0.0.f050,0.0.f051 7 LCS OSA2 3088/60 8c OSE lcs eth 0.0.f060,0.0.f061
Of the pure presentation information, we could drop CU_CARDTYPE, CU_DEVNAME, CHPIDTYPES. Then the selection list in the UI would look like the following.
NUM CU CHPID DRIVER DEVICES 1 1731/01 76 qeth 0.0.f5f0,0.0.f5f1,0.0.f5f2 2 1731/05 87 qeth 0.0.f000,0.0.f001,0.0.f002 3 3088/08 88 ctc 0.0.f020,0.0.f021 4 3088/1f 89 ctc 0.0.f030,0.0.f031 5 3088/1e 8a ctc 0.0.f040,0.0.f041 6 3088/01 8b lcs 0.0.f050,0.0.f051 7 3088/60 8c lcs 0.0.f060,0.0.f061
After activating a certain network adapter, the user currently gets to see one of the following (in case you wonder: This is not necessarily a duplicate of the above selection list, since this also contains the link type/speed. Also the user might have configured manually without even seeing the selection list and still wants to know what he ended up with):
Detected: OSA card in OSD mode, 10 Gigabit Ethernet Detected: OSA card in OSD mode, Gigabit Ethernet Detected: OSA card in OSD mode, Fast Ethernet Detected: OSA card in OSD mode, Gigabit Ethernet, LAN Emulation Detected: OSA card in OSD mode, Fast Ethernet, LAN Emulation Detected: OSA card in OSD mode, Token Ring, LAN Emulation Detected: OSA card in OSD mode, ATM, LAN Emulation Detected: OSA card in OSD mode, unknown link type Detected: OSA card in OSD mode, High Speed Token Ring Detected: OSA for NCP, ESCON/CDLC bridge Detected: HiperSockets with CHPID type IQD Detected: GuestLAN based on OSA (QDIO) Detected: GuestLAN based on HiperSockets Detected: other Detected: OSA LCS card Detected: channel-to-channel adapter (CTC/A) Detected: ESCON Detected: FICON
Without cardtype2cleartext this would reduce to one of:
Detected: OSD_10GIG Detected: OSD_1000 Detected: OSD_100 Detected: OSD_GbE_LANE Detected: OSD_FE_LANE Detected: OSD_TR_LANE Detected: OSD_ATM_LANE Detected: OSD_Express Detected: HSTR Detected: OSN Detected: HiperSockets Detected: GuestLAN QDIO Detected: GuestLAN Hiper Detected: unknown Detected: OSA LCS card Detected: CTC/A Detected: ESCON Detected: FICON
IMHO, this lacks the majority of useful information, which we brought in with this rewrite in the first place.
[2] Currently lacking rawhide on s390x, it's virtually impossible to test and fix. I'm happy to do this as soon as fedora on s390 builds.
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
Hi all,
here is the updated code integrating Jeremy's review comments.
It tries to conform to rawhide as closely as possible and in addition already contains support for all known current s390x network features.
Review and comments greatly appreciated.
attachments are three bash scripts implementing our improvements: linuxrc.s390: initial installation dialog for RHEL on System z (sorry, had to gzip it due to mailing list size limit) lsznet.raw: list sensible network device hardware setups for Linux on System z controlunits.sh: define some common control unit mappings
original references: https://www.redhat.com/archives/anaconda-devel-list/2008-November/msg00183.h... https://www.redhat.com/archives/anaconda-devel-list/2008-December/msg00102.h...
On 02/24/2009 07:03 PM, Steffen Maier wrote:
On 01/05/2009 06:02 AM, Jeremy Katz wrote:
Yeah, I think that given the rearranging, etc, there's an effort which could definitely be made to remove some of the "cruft" rather than just trying to keep the old to keep the old.
Done.
I'll post the updated code for review in another e-mail.
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
#! /bin/bash
# lsznet.raw: list sensible network device hardware setups for Linux on s390(x) # Copyright (C) IBM Corp. 2008,2009 # Author: Steffen Maier maier@de.ibm.com # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License only. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
readonly SYSFS=/sys # DEBUG=0 turns off debugging. >=1 means increasing debugging. readonly DEBUG=0
# nothing to be changed below here
readonly CMD=${0##*/}
function error() { echo "$CMD: ERROR: $*" 1>&2 exit 1; }
# currently requires bash version 3.0 or later
. ./controlunits.sh
# The arrays (among other things) should be adapted, if any of those device # drivers start supporting different CU types/models.
# $CU_CARDTYPE array is the only one which may contain entries with spaces readonly -a CU_CARDTYPE=( "OSA (QDIO)" "HiperSockets" "CTC adapter" "escon channel" "ficon channel" "LCS p390" "LCS OSA" )
readonly -a CU_DEVNAME=( eth hsi ctc ctc ctc eth eth )
readonly -a CU_GROUPCHANNELS=( 3 3 2 2 2 2 2 )
readonly -a CHPIDTYPES=( [10]=OSE [11]=OSD [24]=IQD )
readonly PREFIXFORMAT=[[:xdigit:]]* readonly SSIDFORMAT=[0-3] readonly BUSIDFORMAT=[[:xdigit:]][[:xdigit:]][[:xdigit:]][[:xdigit:]] readonly IDFORMAT=$PREFIXFORMAT.$SSIDFORMAT.$BUSIDFORMAT readonly SUBCHANNEL_TYPE_IO=0
function debug() { level=$1 shift [ $DEBUG -ge $level ] && echo "$*" 1>&2 }
# Returns symbolic name of CHPID type in $chpidtype_symbolic, # if an entry in the array $CHPIDTYPES has been found at index of argument 1. # Returns "?" otherwise. # Always succeeds and returns 0. function search_chpt() { local chpidtype_number=$1 chpidtype_symbolic=${CHPIDTYPES[$chpidtype_number]} if [ "$chpidtype_symbolic" == "" ]; then chpidtype_symbolic="?" fi return 0 }
# build_list: # # Prints list on standard output consisting of all subchannels and # ccwdevices whose control unit type/model match supported network # device types on s390. Each matching entry is accompanied with # (almost all) corresponding attributes. # function build_list() { # use /sys/devices/css*/ for startpath readonly STARTPATH=$SYSFS/devices # change to base directory so path globbing length with find is minimal cd $STARTPATH # fail out gracefully, if there is not expected sysfs environment # (could even fail out near the top, if $(uname -m) != s390x) csses=css$PREFIXFORMAT for d in $csses; do [ -d $d ] || exit done find $csses -name "$IDFORMAT" | while read dir; do debug 6 " examining sysfs directory $dir" # must not use $...FORMAT (file globs) here since this is a regex: [[ "$dir" =~ ^css([[:xdigit:]]+)/([[:xdigit:]]+\.[0-3]\.[[:xdigit:]]{4})/([[:xdigit:]]+\.[0-3]\.[[:xdigit:]]{4})$ ]] case $? in 0) # string matched the pattern debug 6 " ${BASH_REMATCH[@]}" prefix=${BASH_REMATCH[1]} subch=${BASH_REMATCH[2]} devbusid=${BASH_REMATCH[3]} subch_p=css$prefix/$subch dev_p=$subch_p/$devbusid debug 6 " $subch_p $dev_p" ;; 1) # string did not match the pattern continue ;; 2) error "syntax error in regex of match operator =~, code needs to be fixed" ;; *) error "unexpected return code of regex match operator =~, code needs to be fixed" ;; esac debug 5 " sysfs directory matched regex $dir" # skip non-I/O-subchannels, i.e. chsc and message subchannels if [ -f $subch_p/type ]; then read type < $subch_p/type if [ $type != $SUBCHANNEL_TYPE_IO ]; then debug 3 " skip non-I/O subchannel" continue fi fi # get subchannel information... # ATTENTION: hex values from sysfs are WITHOUT leading 0x prefix! read chpid_list < $subch_p/chpids read -a chpids <<< "$chpid_list" if [ ${#chpids[@]} -ne 8 ]; then error "sysfs reported ${#chpids[@]} CHPIDs instead of expected 8" fi read pim pam pom foo < $subch_p/pimpampom pimchpidZ="" local chp for ((chp=0; chp < 8; chp++)); do mask=$((0x80 >> chp)) if (( 0x$pim & $mask )); then pimchpidZ=${pimchpidZ}${chpids[chp]} else pimchpidZ=${pimchpidZ}"ZZ" fi done # get device information... read cutype < $dev_p/cutype read active < $dev_p/online # skip already active subchannels and those that are already in a # ccwgroup and thus not available any more: [ $active == "1" ] && continue [ -h $dev_p/group_device ] && continue # get chpid information... pimchpids=${pimchpidZ//ZZ/} [ $pimchpids == "" ] && continue # Taking the first 2 hex digits as CHPID relies somewhat on the fact # that network adaptors don't use multipathing and only have one CHP. # Anyway it's OK since we're only interested in CHPID type and I guess # this should be equal for all possible multipaths to the same device. chpid=${pimchpids:0:2} chpid_p=css$prefix/chp$prefix.$chpid read chptype < $chpid_p/type # filter and output... if search_cu $cutype; then if [ "${CU_DEVDRV[$cu_idx]}" == "ctcm" ]; then # assume CTC are mostly virtual and ignore chpid from sysfs chpidtype_symbolic="-" else search_chpt $chptype fi echo $pimchpids $devbusid $cutype $chpidtype_symbolic ${CU_DEVDRV[$cu_idx]} ${CU_DEVNAME[$cu_idx]} ${CU_GROUPCHANNELS[$cu_idx]} ${CU_CARDTYPE[$cu_idx]} else debug 5 " skip non-network device $devbusid CU $cutype" fi done }
# search_groups: # # Prints enumeration list on standard output consisting of possible # hardware configurations (ccwgroups) for network devices on s390. # Each configuration suggestion includes corresponding attributes # that are of potential interest for the user and fit in a fixed column # table on an 80 column screen. # # PRECONDITION: Standard input has to be stably sorted by device bus IDs and # then by CHPIDs, i.e. grouped by CHPIDs. # function search_groups() { local w_prefix w_ssid w_devno local d_prefix d_ssid d_devno local prefix ssid devno x local chp devbusid cutype chpidtypename devdrv devname groupchs cardtype # remembered last state variables for possible ccwgroup: local r_prefix="Z" local r_ssid="Z" local r_devno="ZZZZ" local r_chp="ZZ" local r_cutype="ZZZZ/ZZ" local count=0 local item=1 local skipped=0 while read chp devbusid cutype chpidtypename devdrv devname groupchs cardtype; do debug 1 " # $chp $devbusid $cutype $chpidtypename $devdrv $devname $groupchs $cardtype" IFS=. read prefix ssid devno x <<< "$devbusid" unset IFS if [ $r_chp != $chp \ -o $r_prefix != $prefix \ -o $r_ssid != $ssid \ -o $r_cutype != $cutype ]; then # restart with new read channel info and remember it r_prefix=$prefix r_ssid=$ssid r_devno=$devno r_chp=$chp r_cutype=$cutype count=1 debug 2 " INFO: restart on different CHPID or prefix or CUtype/model" continue fi count=$((count + 1)) if [ $count -eq 2 ]; then # about to check if write channel is one above read channel if [ $((0x$devno)) -ne $((0x$r_devno + 1)) ]; then # start with new read channel info r_prefix=$prefix r_ssid=$ssid r_devno=$devno r_chp=$chp r_cutype=$cutype count=1 skipped=$((skipped + 1)) # unimplemented possible packed channel usage option: # remember unused channels for later use as data channel debug 2 " INFO: restart on unmatching read channel" continue fi w_prefix=$prefix w_ssid=$ssid w_devno=$devno elif [ $count -eq 3 ]; then # remember data channel info d_prefix=$prefix d_ssid=$ssid d_devno=$devno fi debug 2 " INFO: groupchs=$groupchs count=$count" if [ $count -ne $groupchs ]; then debug 2 " INFO: skip" continue fi # found possible ccwgroup case $count in 2) chlist=$r_prefix.$r_ssid.$r_devno,$w_prefix.$w_ssid.$w_devno ;; 3) chlist=$r_prefix.$r_ssid.$r_devno,$w_prefix.$w_ssid.$w_devno,$d_prefix.$d_ssid.$d_devno ;; *) error "unknown number of channels for group, code needs to be fixed" ;; esac echo $item $cutype $chp $chpidtypename $devdrv $devname $chlist "$cardtype" item=$((item + 1)) # restart after successful detection r_prefix="Z" count=0 done debug 1 " STATISTIC: skipped $skipped devnos because of unmatching read channel" }
build_list | # stable sort by device bus IDs and then by CHPIDs => grouped by CHPIDs # (sorting only works since keys are fixed no. of digits with leading zeros!) sort -s -k 1,1 -k 2,2 | #cat ; exit # move at desired line and uncomment to see intermediate output search_groups
Steffen Maier wrote:
On 01/05/2009 06:02 AM, Jeremy Katz wrote:
On Thu, 2009-01-01 at 01:27 +0100, Steffen Maier wrote:
On 12/07/2008 04:56 PM, Jeremy Katz wrote:
- A lot of checking for things like a 2.6 kernel. There's
_always_ going to be at least a 2.6 kernel and such checks just needlessly complicate the script, making it that much harder to see what's really going on
I suspect you mean the two places in linuxrc where we check for at least Linux 2.6.26 which is when IPv6 support for HiperSockets in layer 3 mode went upstream.
[snip]
But a kernel version doesn't tell you those things -- distros backport kernel changes all the time. You have to instead check based on functionality being provided rather than assuming anything off of the kernel version.
Alas, there is nothing to check for this functionality. Knowing that the functionality will be in the kernel, the user is now unconditionally allowed to make use of it.
If there is no way to test for functionality and it's entirely dependent on checking the kernel version, it becomes an ongoing thing to maintain in anaconda. We try to avoid this when possible.
There is really no way via /proc or /sys to check for this functionality?
- Are udev and friends getting installed into the s390 initrd
right now?
Just a minimum base consisting of udevd and udevsettle just for calling
[snip]
My point was that I don't think that the scripts which generate the s390 initramfs (mk-images.s390) are pulling in the udev bits at the moment. Which means this won't work as-is.
Correct. As mentioned earlier, it's necessary to add some new stuff to mk-images.s390. The first comment after the license header in linuxrc.s390 lists the prerequisites.
OK, we'll have to make sure to patch that script as well.
- Some of the stuff in lsznet makes me think that modules should
be getting auto-loaded by udev given the existence of modaliases and matching against things in /sys/bus/ccw
[snip]
In case you were referring to the arrays related to CU type/model: They are there for mapping the values in sysfs to user-friendly strings that appear in the generated table of possible network hardware configurations. Since they contain more information than what is in modalias, alas, they cannot all be automatically extracted from the kernel modules. E.g. cardtype, devname, and groupchannels cannot be deduced automatically.
This information *really* needs to be provided from the kernel. Otherwise, we're going to be carrying duplicates of it in anaconda.
They are only duplicates insofar as this information is in the driver code, e.g. conditional branches. It is being discussed to add this information as driver-specific sysfs-attributes with static content. Since we don't expect this to make it for F11, I left the mapping arrays in the code. See also [1].
That's good. This information should end up in the drivers, not anaconda.
With regard to linuxrc.s390, the way kernel modules are treated -- namely explicitly loaded including dependencies -- has been taken from the existing linxurc.s390 in order to introduce as few as possible changes.
It's already a complete rewrite to the point that diff is useless. So ditch the cruft. Reviewing in between the cruft being kept to try to "minimize" changes just makes life more painful
Removed all kernel module handling (insmod/rmmod). Please be aware, that we now fully rely on automatic loading of (driver) modules, which may very well need some adaptations to the building of the initrd. See also [2].
That's doable. Making s390 work more like the other architectures is good (as in, automatic module loading).
- Manual mknods shouldn't ever need to be present; udev should be
creating device nodes
[snip]
Since this is going to rawhide, we should have a more fully-fledged udev environment. So the cruft needs to go.
Those manual mknods, that are in linuxrc.s390, are exactly the ones that are in the current init.c of rawhide.
init.c hasn't changed in a while, so it may have some unnecessary code in it these days.
- modprobe instead of insmod if modules have to be manually
loaded so that at least dependent modules can be auto-loaded. This also lets us kill the $LO hack
[snip]
existing linuxrc.s390. In fact, insmod and friends come from busybox
[snip]
$LO comes from the switch from .o files to .ko files with kernel modules going from 2.4 -> 2.6. It's mindless noise that should really be dropped. Also, we really don't want to use busybox insmod, etc at this point -- we should just use the pieces from module-init-tools.
Dropped the $LO stuff and any manual (un)loading of kernel modules completely.
Sorry for confusion with the busybox insmod. In fact, it is the loader which also acts as insmod and rmmod if called with that name. If this is still a problem, I'm fine with using module-init-tools instead. But then we need to add them to the installer initrd and also rework the way kernel modules are packaged in the initrd.
Using the tools that the target system will be running is preferred, so that would be module-init-tools. Unless it proves completely impossible, which I think is unlikely.
- cardtype2cleartext() is the sort of thing which gets out of
date and then becomes critical must fix bugs... if this information is
[snip]
The output of cardtype2cleartext is for information presented to the user on the screen.
[snip]
Then add a new sysfs value. You guys are the upstream of the kernel module
Since this is presentation information, opinions were that this is not exactly something for the kernel but rather for user space. For the time being I left it in the code. See also [1].
There's a difference between presentation code and a descriptive string. All we need the kernel to provide is the descriptive string. That shouldn't be maintained in a list outside of the kernel because then it becomes impossible to maintain.
Do:
cd /lib/modules/VERSION/kernel/drivers/net modinfo *.ko | grep description
We need to avoid maintaining lists of descriptive strings to driver names in anaconda.
[1] This is what parts of the user output currently look like. It contains a reasonable amount of information that allows the user to match this to whatever he has been told by his sysprog who configured the LPAR or VM guest.
NUM CARD CU CHPID TYPE DRIVER IF DEVICES 1 OSA (QDIO) 1731/01 76 OSD qeth eth 0.0.f5f0,0.0.f5f1,0.0.f5f2 2 HiperSocket 1731/05 87 IQD qeth hsi 0.0.f000,0.0.f001,0.0.f002 3 CTC adapter 3088/08 88 ctc ctc 0.0.f020,0.0.f021 4 escon channel 3088/1f 89 ctc ctc 0.0.f030,0.0.f031 5 ficon channel 3088/1e 8a ctc ctc 0.0.f040,0.0.f041 6 LCS p390 3088/01 8b lcs eth 0.0.f050,0.0.f051 7 LCS OSA2 3088/60 8c OSE lcs eth 0.0.f060,0.0.f061
Of the pure presentation information, we could drop CU_CARDTYPE, CU_DEVNAME, CHPIDTYPES. Then the selection list in the UI would look like the following.
NUM CU CHPID DRIVER DEVICES 1 1731/01 76 qeth 0.0.f5f0,0.0.f5f1,0.0.f5f2 2 1731/05 87 qeth 0.0.f000,0.0.f001,0.0.f002 3 3088/08 88 ctc 0.0.f020,0.0.f021 4 3088/1f 89 ctc 0.0.f030,0.0.f031 5 3088/1e 8a ctc 0.0.f040,0.0.f041 6 3088/01 8b lcs 0.0.f050,0.0.f051 7 3088/60 8c lcs 0.0.f060,0.0.f061
After activating a certain network adapter, the user currently gets to see one of the following (in case you wonder: This is not necessarily a duplicate of the above selection list, since this also contains the link type/speed. Also the user might have configured manually without even seeing the selection list and still wants to know what he ended up with):
Detected: OSA card in OSD mode, 10 Gigabit Ethernet Detected: OSA card in OSD mode, Gigabit Ethernet Detected: OSA card in OSD mode, Fast Ethernet Detected: OSA card in OSD mode, Gigabit Ethernet, LAN Emulation Detected: OSA card in OSD mode, Fast Ethernet, LAN Emulation Detected: OSA card in OSD mode, Token Ring, LAN Emulation Detected: OSA card in OSD mode, ATM, LAN Emulation Detected: OSA card in OSD mode, unknown link type Detected: OSA card in OSD mode, High Speed Token Ring Detected: OSA for NCP, ESCON/CDLC bridge Detected: HiperSockets with CHPID type IQD Detected: GuestLAN based on OSA (QDIO) Detected: GuestLAN based on HiperSockets Detected: other Detected: OSA LCS card Detected: channel-to-channel adapter (CTC/A) Detected: ESCON Detected: FICON
Without cardtype2cleartext this would reduce to one of:
Detected: OSD_10GIG Detected: OSD_1000 Detected: OSD_100 Detected: OSD_GbE_LANE Detected: OSD_FE_LANE Detected: OSD_TR_LANE Detected: OSD_ATM_LANE Detected: OSD_Express Detected: HSTR Detected: OSN Detected: HiperSockets Detected: GuestLAN QDIO Detected: GuestLAN Hiper Detected: unknown Detected: OSA LCS card Detected: CTC/A Detected: ESCON Detected: FICON
IMHO, this lacks the majority of useful information, which we brought in with this rewrite in the first place.
The cardtype2cleartext output certainly improves what the user sees, but if those strings could be provided either by modinfo or through sysfs, that would be easier going forward.
That way other userspace things beyond just anaconda can make use of those strings (for example, maybe system-config-network). If they are not provided by the driver, we end up maintaining them in many places across the distribution which seems like a waste of effort.
How it's provided by the kernel is really up to the kernel, but so long as the descriptive strings are maintained by the same people doing the drivers, that's what we're really after.
[2] Currently lacking rawhide on s390x, it's virtually impossible to test and fix. I'm happy to do this as soon as fedora on s390 builds.
I hear we are getting closer on rawhide on s390x, so one day... :)
On 02/24/2009 09:08 PM, David Cantrell wrote:
Steffen Maier wrote:
On 01/05/2009 06:02 AM, Jeremy Katz wrote:
On Thu, 2009-01-01 at 01:27 +0100, Steffen Maier wrote:
On 12/07/2008 04:56 PM, Jeremy Katz wrote:
- A lot of checking for things like a 2.6 kernel. There's
_always_ going to be at least a 2.6 kernel and such checks just needlessly complicate the script
I suspect you mean the two places in linuxrc where we check for at least Linux 2.6.26 which is when IPv6 support for HiperSockets in layer 3 mode went upstream.
[snip]
But a kernel version doesn't tell you those things -- distros backport kernel changes all the time. You have to instead check based on functionality being provided rather than assuming anything off of the kernel version.
Alas, there is nothing to check for this functionality. Knowing that the functionality will be in the kernel, the user is now unconditionally allowed to make use of it.
If there is no way to test for functionality and it's entirely dependent on checking the kernel version, it becomes an ongoing thing to maintain in anaconda. We try to avoid this when possible.
This won't be a problem since this feature won't go away in the future.
There is really no way via /proc or /sys to check for this functionality?
No. I had talked to our network driver maintainers to confirm this and also suggested to have such checking possibilities for future features.
- Manual mknods shouldn't ever need to be present; udev should be
creating device nodes
[snip]
Since this is going to rawhide, we should have a more fully-fledged udev environment. So the cruft needs to go.
Those manual mknods, that are in linuxrc.s390, are exactly the ones that are in the current init.c of rawhide.
init.c hasn't changed in a while, so it may have some unnecessary code in it these days.
I'll remove the manual mknods as soon as we have a working test environment and can validate that this won't break anything (or if init.c gets updated because somebody else confirms removal is OK).
- cardtype2cleartext() is the sort of thing which gets out of
date and then becomes critical must fix bugs...
[snip]
The output of cardtype2cleartext is for information presented to the user on the screen.
[snip]
Then add a new sysfs value. You guys are the upstream of the kernel module
Since this is presentation information, opinions were that this is not exactly something for the kernel but rather for user space.
There's a difference between presentation code and a descriptive string. All we need the kernel to provide is the descriptive string. That shouldn't be maintained in a list outside of the kernel because then it becomes impossible to maintain.
I see your point.
cd /lib/modules/VERSION/kernel/drivers/net modinfo *.ko | grep description
Some notes, just for completeness:
This will only present the driver modules and their descriptions (filtered to show only those relevant to installer):
# (cd /lib/modules/`uname -r`/kernel/drivers/s390/net/ && modinfo *.ko | fgrep -e filename: -e description:) filename: ctc.ko description: Linux for S/390 CTC/Escon Driver filename: lcs.ko filename: netiucv.ko description: Linux for S/390 IUCV network driver filename: qeth.ko description: Linux on zSeries OSA Express and HiperSockets support
(Oops, just figured that lcs misses a description. Going to report this to maintainer.)
However, qeth alone supports a bunch of different adapter types. Those 14 items are what cardtype2cleartext translates. I.e. static driver descriptions don't help here. We need a new sysfs attribute per device just as the existing cardtype attribute but with a user friendly string.
That way other userspace things beyond just anaconda can make use of those strings (for example, maybe system-config-network).
Agreed. I'll try to convince our maintainers that a new sysfs attribute is a good thing.
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
On 02/24/2009 07:03 PM, Steffen Maier wrote:
On 01/05/2009 06:02 AM, Jeremy Katz wrote:
On Thu, 2009-01-01 at 01:27 +0100, Steffen Maier wrote:
On 12/07/2008 04:56 PM, Jeremy Katz wrote:
Removed all kernel module handling (insmod/rmmod). Please be aware, that we now fully rely on automatic loading of (driver) modules, which may very well need some adaptations to the building of the initrd. See also [2].
Also, trying to switch to auto-loading using udev would at least for the network types LCS and CTC which are based on cu3088 not be straight forward.
[snip]
Then the drivers need to be fixed. Period. As of rawhide, *ANYTHING* calling modprobe for something which would be considered a "driver" is a bug.
I was told, our drivers have been fixed upstream. However, this most probably won't make it into F11, so I'm going to provide some udev rules that help automatically loading the necessary modules.
Here is my promised udev rule to load LCS and CTC and thus all current network devices drivers on s390x automatically. I'm still a bit unsure where exactly to put it between all existing rules. At least it worked in an F9 based internal build for s390x. The rule definitely has to be before /etc/udev/rules.d/55-ccw.rules. Here we go /etc/udev/rules.d/54-cu3088-fix.rules:
# LCS ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/01", RUN+="/sbin/modprobe --quiet lcs" ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/60", RUN+="/sbin/modprobe --quiet lcs" # could be either CTC or LCS ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet ctcm" ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet lcs" # CTC ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1E", RUN+="/sbin/modprobe --quiet ctcm" ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1F", RUN+="/sbin/modprobe --quiet ctcm"
Comments greatly appreciated.
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
Steffen Maier (maier@linux.vnet.ibm.com) said:
Here is my promised udev rule to load LCS and CTC and thus all current network devices drivers on s390x automatically. I'm still a bit unsure where exactly to put it between all existing rules. At least it worked in an F9 based internal build for s390x. The rule definitely has to be before /etc/udev/rules.d/55-ccw.rules. Here we go /etc/udev/rules.d/54-cu3088-fix.rules:
# LCS ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/01", RUN+="/sbin/modprobe --quiet lcs" ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/60", RUN+="/sbin/modprobe --quiet lcs" # could be either CTC or LCS ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet ctcm" ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/08", RUN+="/sbin/modprobe --quiet lcs" # CTC ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1E", RUN+="/sbin/modprobe --quiet ctcm" ACTION=="add", SUBSYSTEM=="ccw", SYSFS{cutype}=="3088/1F", RUN+="/sbin/modprobe --quiet ctcm"
Comments greatly appreciated.
This seems like the sort of thing that could be automated with modaliases in the driver and sysfs.
Bill
On 03/04/2009 06:42 PM, Bill Nottingham wrote:
Steffen Maier (maier@linux.vnet.ibm.com) said:
Here is my promised udev rule to load LCS and CTC and thus all current network devices drivers on s390x automatically.
This seems like the sort of thing that could be automated with modaliases in the driver and sysfs.
May I quote from my previous mail:
On 03/04/2009 06:21 PM, Steffen Maier wrote:
On 02/24/2009 07:03 PM, Steffen Maier wrote:
I was told, our drivers have been fixed upstream. However, this most probably won't make it into F11, so I'm going to provide some udev rules that help automatically loading the necessary modules.
So again, we're already working on fixing the drivers just as you and Jeremy previously suggested. For the time being this udev hack enables what you asked for, namely automatic loading of drivers. This all helps to get Fedora on s390x going.
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@lists.fedoraproject.org
-
Bill Nottingham -
David Cantrell -
Jeremy Katz -
Steffen Maier