On Mon, Apr 14, 2014 at 5:11 PM, Jarod Wilson <jarod(a)redhat.com> wrote:
On Tue, Apr 01, 2014 at 12:50:33PM -0400, Josh Boyer wrote:
> This creates kernel-core and kernel-drivers subpackages. The kernel package
> remains as a meta-package the requires both of the subpackages. This allows
> most installs to continue on as-is with upgrades working.
> The contents of the kernel-core and kernel-drivers subpackages are determined
> at build time through the filter-modules.sh script. This script "removes"
> pre-defined subsystems and modules and generates a filelist for the %files
> section of each subpackage. The contents of each are per-arch, with arch
> override files taken into account. This allows us to make the split useful
> for varying arches.
I think there needs to be a little bit more documentation surrounding
this. If one simply cracks open a filter-$arch.sh file, they really don't
get any clue how these two variables are used, where things listed end up,
etc. A blurb in each of them explaining "files added to these lists are
excluded from kernel-core and stashed in kernel-drivers" (assuming I even
got that much right from a quick read) would be useful. Somewhere down the
road, I'm sure someone other than yourself will need to make a change to
one of those lists. I'm pretty familiar with the kernel spec myself, and
without some trial and error, poking at builds, I can't say for certain I
actually understand exactly what ends up where.
OK, totally fair. FWIW, you did get it correct for the most part.
Now, as for reusability... No clue if this is something that would
desired down the road in Red Hat Enterprise Linux (RHEL). Making this a
toggle-able (e.g. --with split) option would be potentially nifty, but
with all the macro crud, a hideous mess to implement. I can see this being
I considered wrapping it with something like %if with_split, but that
does indeed get nasty. Also, within the context of Fedora, it would
basically be an option that was either always on or always off. We
couldn't really make it arch tunable because of potential changes to
anaconda to expect kernel-core to exist, etc. Trying to deliver two
different "kernel" packages seems pretty difficult in that regard.
potentially useful in the RHEL case too though -- people installing
appliances, barebones servers, etc., might like the disk space savings not
having tons of useless drivers installed too. I think we can make the case
that its a good idea to split things up this way, and worst-case, its not
horrendously hard to gut things back to the way they are now.
I was hoping it would be useful at some point, yeah. Whether that
happens remains to be seen, but at least I'll try keeping things in
mind as we go. If there are changes that would help going forward, I
hope people bring those up as soon as possible when they think of
1) Is there a default destination for any "new" driver that shows up in
the tree? I assume that will partly depend on where it ends up in the file
system hierarchy, but maybe it is something that needs to be monitored to
prevent sudden and unexpected bloat to -core (i.e., new subsystem gets
enabled by way of some kconfig option, all winds up in -core, increasing
its size significantly).
New drivers are mostly at the mercy of where they are in the subsystem
directories. Any new driver that gets lumped into a subsys that's
moved to -drviers will wind up there. For subsystems that aren't
already lumped into -drivers, new drivers would wind up in -core.
There's a depmod check to make sure we don't have -core wind up with
unmet module dependencies, and that will be fatal during build (I
still need to make that change).
I agree we need to watch the size issue, and we might be able to put a
check on the module tree after we move stuff around. However, there's
no strict limit on what that size should be. What I have here is a
first approximation of a trimmed down size and it seems to be suitable
to start with. Don was trying to advocate for a "quota" and I still
think that's worthwhile in the longer run.
2) What criteria are being used to determine what goes into core?
Fedora feature page says core is "a minimum(-ish) set of drivers to only
just be able to run in virtualized environments", which I hadn't read yet
when I suggested maybe RHEL barebones servers would use this. I think I'd
like to see a bit larger core than just-enough-for-virt myself. To me,
what anaconda needs to install a system and get it on the network to
receive updates maybe better describes what I'd consider core than
just-enough-for-virt does. No clue how bit the delta is there though.
It's a bit more than just-virt. E.g. we have the radeon and intel
video drivers in there, all the major rootfs filesystems (btrfs, xfs,
ext4), and a variety of other drivers included. Using just
kernel-core does boot a KVM guest without any missing functionality
(unless you're doing passthru perhaps), so that is the main testcase
but that doesn't mean it has to be the only thing that works. It
likely isn't enough for a barebones server at the moment, but it isn't
far off. Others have asked if kernel-core would be suitable for
"embedded" devices, and the answer there is maybe. I wouldn't expect
it to be suitable for something like a laptop, which would require all
the various sound drivers and other niceties to make the hardware