On Mon, Apr 14, 2014 at 5:11 PM, Jarod Wilson <jarod@xxxxxxxxxx> 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 be > 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 virt > 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 them. > Some questions: > > 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? The > 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 work. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
