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... :)
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
