[WIP] Create kernel-core and kernel-drivers subpackages

Don Zickus dzickus at redhat.com
Thu Mar 20 19:29:12 UTC 2014


On Thu, Mar 20, 2014 at 02:51:13PM -0400, Josh Boyer wrote:
> On Thu, Mar 20, 2014 at 02:13:20PM -0400, Don Zickus wrote:
> > On Mon, Mar 17, 2014 at 03:13:54PM -0400, Josh Boyer wrote:
> > > TODO:
> > > 
> > > Right now this is what has been building in my COPR for the past week.
> > > It works well on x86_64 (which is all I've tested), and i686 builds but
> > > I know it's broken on ARM.  To finish it up, I need:
> > > 
> > > 1) Review from you all.
> > 
> > I took a stab at this.
> 
> Thanks!
> 
> 
> > Let's start with the dumb question first because I couldn't find the
> > obvious answer, why kernel-driver? and not just kernel and
> > kernel-modules-extras?  IOW what does kernel-core buy us except for spec
> > churn.  I am sure yum is invovled in that answer.
> 
> kernel -> metapackage the requires the equivalent of what kernel is
> today.
> kernel-core -> the tiny thing Cloud wants.  vmlinux + a small set of
> drivers
> kernel-drivers -> the other "half" of what kernel is today
> kernel-modules-extra -> modules that really aren't needed anywhere by
> default and I wish we could just turn off entirely.
> 
> So kernel-modules-extra already exists today and repurposing it to be
> the equivalent of kernel-drivers could happen I guess.  However, just
> having "kernel" be the tiny thing is probably broken from a conceptual
> standpoint because just installing kernel isn't enough to fully boot on
> most bare-metal machines.  If we made it so, then it would probably be
> large enough to just not bother with this at all.  Hence kernel-core.

Right, I guess I don't understand how kernel-drivers magically
installs/not installs.  I had assumed some of this was hardcoded in some
install file anaconda reads.  So my initial assumption was kernel and
kernel-drivers would auto install on a normal desktop.  I didn't think far
enough to understand how an update would work..

So in this case, I suppose cloud only installs kernel-core whereas desktop
installs kernel (which installs both -core and -driver)?

> 
> > Second, the whole mv .. restore/ and back again dance made me cry.  Can we
> > just hack the scripts/Makefile.modinst file to pass a filter argument such
> > that the installs look like
> > 
> > #kernel core
> > make modules_install INSTALL_MOD_DIR=core INSTALL_MOD_FILTER=modules.list
> > #kernel module extras
> > make modules_install INSTALL_MOD_DIR=suppl INSTALL_MOD_FILTER_INV=modules.list
> > 
> > then you have two directories core/ and suppl/ that you can run depmod on
> > individually and for filelist purposes.  Then you can combine it later for
> > packaging purposes I think.  Something like that.  Heck you might be able
> > to run a depmod check on the filtered files and fail if a dependency isn't
> > copied over during install (or just do it automagically to keep
> > modules.list smaller).
> 
> Er... no?  I mean, we could install to core and suppl directories if we
> had modules.list.  But if we had modules.list already then we wouldn't
> need to generate the %files list, which is what this hunk is doing.
> 
> Essentially this is avoiding hardcoded, one line per .ko lists by going
> through and removing entire directories of things and saving off the
> list as the contents of kernel-core and kernel-drivers.  Then we fix it
> up since we actually want kernel-drivers to install to
> /lib/modules/`uname -r`/kernel/ also.
> 
> It's probably clearer if you have filter-modules.sh to look at.  I've
> attached it below.  Apologies for not including it to begin with.

Ah, yes, now things are clearer.  I had assumed you were listing
everything one by one (sorta akin to what is done with the config
options).

I could argue you would have better control if you mimic'd the config
options and created a modules.list.  But I am not maintaining this, so I
won't. :-)

> 
> > Most of this is just moving and renaming so that isn't too bad.  I didn't
> > focus on the small subtle changes on the %post stuff.
> 
> Yeah, that's fairly trivial.
> 
> > I keep telling myself I would love to rework the spec file to simplify
> > again by moving some of the junk into rpm properly.  The number of people
> > who can fully understand the spec file is becoming a dying breed. :-(
> > 
> > So all this churn doesn't make it any better.  Hence why I was looking for
> > kernel Makefile solutions or other rpm solutions to simplify the quirks.
> 
> Except the complexities don't come from the kernel makefiles.  They come
> from RPM :\.  It needs a file with a list of files to include for the
> %files -f directive of both kernel-core and kernel-drivers to work.  If
> we don't use %files -f, we're stuck listing out individual directories
> and .ko files in the %files section for each.  That would be a nightmare
> to maintain, so I've automated it with %files -f.

I wasn't referring to the %files stuff.  More like all the shell scripting
prep work for restore/ and friends.  Just trying to think of ways to
simplify things.

> 
> Some of this could be avoided (not a whole lot) if we invented
> /lib/modules/`uname -r`/suppl and installed the kernel-drivers content
> there, but that's yet-another location for things.  I'm not overly
> thrilled with doing that.  All it would really avoid is the restore we
> do.
> 
> > > 2) A per-arch filter list, because the existing one that works on
> > > x86_64 leaves modules in kernel-core on ARM that lack their
> > > dependencies.  Bad.
> > 
> > Much like the config files?
> 
> Eh, not really.  It's a list of directories and individual .ko files to
> filter out.  Example filter-x86_64.sh file also below.
> 
> > > 3) Further testing on all arches.
> > > 
> > > 4) To make the depmod call fatal to the build.  Without making this
> > > fatal we run the risk of pushing kernel-core packages that aren't
> > > self-contained and that seems pretty bad to me.  It shouldn't be a huge
> > > issue as I would think most of the breakage is going to come from merge
> > > window stuff and settle down after that.
> > 
> > I was trying to envision a 'make depcheck' or something similar to a 'make
> > configs' that fails early as opposed to an hour after the build completes.
> > But everytime I dive to deep into the Makefile I get lost, try a quick
> > hack and make things worse (I still dream of a 'make kabi' like command
> > for rhel reasons...).
> 
> That... wouldn't help here.  The configs are untouched, and Kconfig
> should already gripe if you have a config set that doesn't have a dep
> set.  You actually need the built modules in the locations they're going
> to be installed at in order to run depmod and ensure the required .ko
> _files_ are present.  I really don't see a way to avoid building the
> drivers here.

I didn't explain myself clearly.  The idea was if you had a list, you
could somehow run it through Kconfig (or Makefile) and check that all the
deps were on the list and fail at pre-build time with a broken dependency
on your module.list.  However, with the way you are doing it, this
obviously can't work as you don't know what is on your list until after
you build.


Thanks for the filter-modules.sh script, it cleared things up.

Cheers,
Don

> 
> josh
> 
> diff --git a/filter-modules.sh b/filter-modules.sh
> new file mode 100755
> index 0000000..b06a8b9
> --- /dev/null
> +++ b/filter-modules.sh
> @@ -0,0 +1,111 @@
> +#! /bin/bash
> +#
> +# Called as filter-modules.sh list-of-modules Arch
> +
> +# Grab the arch-specific filter lists
> +source ./filter-$2.sh
> +
> +filter_dir() {
> +	filelist=$1
> +	dir=$2
> +
> +	grep -v -e "${dir}/" ${filelist} > ${filelist}.tmp
> +
> +	if [ $? -ne 0 ]
> +	then
> +		echo "Couldn't remove ${dir}.  Skipping."
> +	else
> +		grep -e "${dir}/" ${filelist} >> k-d.list
> +		mv ${filelist}.tmp $filelist
> +	fi
> +	
> +	return 0
> +}
> +
> +filter_ko() {
> +	filelist=$1
> +	mod=$2
> +
> +	grep -v -e "${mod}.ko" ${filelist} > ${filelist}.tmp
> +
> +	if [ $? -ne 0 ]
> +	then
> +		echo "Couldn't remove ${mod}.ko  Skipping."
> +	else
> +		grep -e "${mod}.ko" ${filelist} >> k-d.list
> +		mv ${filelist}.tmp $filelist
> +	fi
> +	
> +	return 0
> +}
> +
> +# Filter the drivers/ subsystems
> +for subsys in ${driverdirs}
> +do
> +	filter_dir $1 drivers/${subsys}
> +done
> +
> +# Filter the networking drivers
> +for netdrv in ${netdrvs}
> +do
> +	filter_dir $1 drivers/net/${netdrv}
> +done
> +
> +# Filter the ethernet drivers
> +for eth in ${ethdrvs}
> +do
> +	filter_dir $1 drivers/net/ethernet/${eth}
> +done
> +
> +# SCSI
> +for scsi in ${scsidrvs}
> +do
> +	filter_dir $1 drivers/scsi/${scsi}
> +done
> +
> +# TTY
> +for tty in ${ttydrvs}
> +do
> +	filter_dir $1 drivers/tty/${tty}
> +done
> +
> +# USB
> +for usb in ${usbdrvs}
> +do
> +	filter_dir $1 drivers/usb/${usb}
> +done
> +
> +# Filesystems
> +for fs in ${fsdrvs}
> +do
> +	filter_dir $1 fs/${fs}
> +done
> +
> +# Network protocols
> +for prot in ${netprots}
> +do
> +	filter_dir $1 kernel/net/${prot}
> +done
> +
> +# DRM
> +for drm in ${drmdrvs}
> +do
> +	filter_dir $1 drivers/gpu/drm/${drm}
> +done
> +
> +# Just kill sound.
> +filter_dir $1 kernel/sound
> +
> +# Now go through and filter any single .ko files that might have deps on the
> +# things we filtered above
> +for mod in ${singlemods}
> +do
> +        filter_ko $1 ${mod}
> +done
> +
> +# Go through our generated drivers list and remove the .ko files.  We'll
> +# restore them later.
> +for mod in `cat k-d.list`
> +do
> +	rm -rf $mod
> +done
> diff --git a/filter-x86_64.sh b/filter-x86_64.sh
> new file mode 100644
> index 0000000..4d9fe44
> --- /dev/null
> +++ b/filter-x86_64.sh
> @@ -0,0 +1,21 @@
> +#! /bin/bash
> +
> +driverdirs="atm auxdisplay bcma bluetooth fmc iio infiniband isdn leds media memstick message mfd mmc mtd nfc ntb pcmcia platform power ssb staging uio uwb"
> +
> +netdrvs="appletalk dsa hamradio ieee802154 irda ppp slip usb wireless"
> +
> +ethdrvs="3com adaptec alteon amd atheros broadcom cadence calxeda chelsio cisco dec dlink emulex icplus marvell mellanox neterion nvidia oki-semi packetengines qlogic rdc renesas sfc silan sis smsc stmicro sun tehuti ti wiznet xircom"
> +
> +scsidrvs="aacraid aic7xxx aic94xx be2iscsi bfa bnx2i bnx2fc csiostor cxgbi esas2r fcoe fnic isci libsas lpfc megaraid mpt2sas mpt3sas mvsas pm8001 qla2xxx qla4xxx sym53c8xx_2 ufs"
> +
> +ttydrvs="ipwireless"
> +
> +usbdrvs="atm wusbcore"
> +
> +fsdrvs="affs befs coda cramfs dlm ecryptfs hfs hfsplus isofs jfs minix ncpfs nilfs2 ocfs2 reiserfs romfs squashfs sysv ubifs udf ufs"
> +
> +netprots="appletalk atm ax25 batman-adv bluetooth dccp dsa ieee802154 irda l2tp mac80211 mac802154 netrom nfc rds rfkill rose sctp wireless"
> +
> +drmdrvs="ast gma500 mgag200 via nouveau"
> +
> +singlemods="ntb_netdev iscsi_ibft iscsi_boot_sysfs iscsi_tcp megaraid pmcraid qla1280 9pnet_rdma svcrdma xprtrdma hid-picolcd hid-prodikeys hwa-hc hwpoison-inject hid-sensor-hub"


More information about the kernel mailing list