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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
