On Wed, Oct 30, 2013 at 11:12 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 10/30/2013 11:10 AM, Simo Sorce wrote:
>> On Wed, 2013-10-30 at 10:16 -0400, Josh Boyer wrote:
>>> [ Resend with the right server mailing list address. Sorry
>>> kernel@ people.]
>>> Hi All,
>>> I realize the WG is just forming up and you have a lot of other
>>> items to cover for now, but I wanted to get this sent out and
>>> have people start thinking about it sooner rather than later.
>>> The kernel team is interested in what the Server WG sees as its
>>> requirements for the kernel package. Does today's kernel image
>>> mostly suit those needs already, or are there changes that would
>>> be beneficial?
>>> While you think about this, please keep in mind that the kernel
>>> team really wants to keep a single kernel package across all 3
>>> products as much as possible. We won't scale to providing
>>> multiple kernel packages or vmlinux binaries for each product.
>>> At the moment, we're essentially looking for a good "core" kernel
>>> package that suits cloud, server, and workstation and then at
>>> repackaging the drivers into subpackages where appropriate.
>>> If you have changes you'd like to see, please let us know what
>>> they are and the reasoning behind those changes. Hopefully we
>>> can work with all 3 WGs and come up with something suitable for
>>> everyone. Thanks for your time.
>> Personally I think that as long as the kernel is modular and all
>> useful modules are available, the Server WG should not have trouble
>> with it.
>> I guess the installation procedure (hence Anaconda) need to be
>> somewhat customizable so that the server image is by default a lot
>> friendlier to the type of hardware a server gets to use, and the
>> kind of defaults that make more sense for a server vs say desktop
>> or cloud.
>> But I think all this can be built easily above a common kernel.
> I agree as well. A common kernel is paramount.
OK, good. To be fair, I didn't think there would be many requirements
from the Server WG. Most of the packaging changes will likely be
driven by the Cloud WG. At the moment, it shouldn't be difficult for
Server to install both the small base kernel package and the larger
kernel-drivers subpackage (for example).
At the same time, it would be good to look over what the current
kernel is providing and see if you notice any glaring omissions in
either drivers or settings. Or at the very least, perhaps define what
kind of machines you will be targeting with the Server WG spin.
Massive 4096 multi-cored CPU machines with terabytes of DRAM and
petabytes of storage, or more commodity style hardware used in
heterogeneous environments, etc. Hopefully the impacts to the kernel
there will be minimal, but it would help us understand what you're
shooting for so we can keep it in mind.
I realize the WG is just forming up and you have a lot of other items
to cover for now, but I wanted to get this sent out and have people
start thinking about it sooner rather than later.
The kernel team has heard in the past that the Cloud group would like
to see something of a more minimal kernel for usage in cloud images.
We'd like to hear the requirements for what this smaller image would
need to cover.
Right now, a default x86_64 kernel package on f20 is ~134MB installed.
Most of that is device drivers installed in /lib/modules/`uname -r`/.
The vmlinux binary is about 5MB and the initramfs (which is created
at install time and can actually vary quite widely depending on
various things) is about 11MB. Drivers can be trimmed to a degree,
but please keep in mind that the kernel is already relatively small
for the functionality it provides. For example, it is not much bigger
than glibc-common (119MB).
So, some caveats to keep in mind while you're thinking about this:
1) We're mostly talking about packaging here, not building a separate
cloud kernel package or vmlinux. The kernel team really wants to have
a single vmlinux across the 3 products if at all possible. We can't
scale to much else.
2) What usecases is the cloud image going to cover? E.g. is it just
virtio stuff, or will it also fit PCI passthru (which then requires
drivers for those PCI devices)?
3) What are the common provisioning requirements that are driving the
size reduction? (See comment about glibc-common. I would think
change is needed in multiple packages, not just the kernel.)
4) Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
On Thu, Oct 24, 2013 at 3:29 PM, Peter Robinson
> commit ac67590916a449d1e71a791f6a0c3688251ec074
> Author: Peter Robinson <pbrobinson(a)gmail.com>
> Date: Thu Oct 24 20:29:40 2013 +0100
> Add patch for i.MX6 Utilite device dtb, drop old exynos patch
I thought we discussed on IRC that patches were going to get sent to
the list first?
> diff --git a/config-arm-generic b/config-arm-generic
> index 96a95e5..aaa88ee 100644
> --- a/config-arm-generic
> +++ b/config-arm-generic
> @@ -114,8 +114,6 @@ CONFIG_MFD_CORE=m
Why did this get dropped? The commit message doesn't say.
> # CONFIG_CRYPTO_TEST is not set
> # CONFIG_TRANSPARENT_HUGEPAGE is not set
> # CONFIG_XEN is not set
> diff --git a/kernel.spec b/kernel.spec
> index d1ea97d..19e9e4e 100644
> --- a/kernel.spec
> +++ b/kernel.spec
> @@ -675,7 +675,6 @@ Patch15000: nowatchdog-on-virt.patch
> # lpae
> Patch21001: arm-lpae-ax88796.patch
> Patch21004: arm-sound-soc-samsung-dma-avoid-another-64bit-division.patch
> -Patch21005: arm-exynos-mp.patch
> # ARM omap
> Patch21010: arm-omap-load-tfp410.patch
> @@ -683,6 +682,10 @@ Patch21010: arm-omap-load-tfp410.patch
> # ARM tegra
> Patch21020: arm-tegra-usb-no-reset-linux33.patch
> +# ARM i.MX6
> +# http://www.spinics.net/lists/devicetree/msg08276.html
> +Patch21030: arm-imx6-utilite.patch
The link to the discussion is nice and I appreciate it. Though it
shows that changes have been requested, the patch isn't queued, and it
isn't really fully reviewed.
I don't understand the urgency in adding something that doesn't appear
to be ready according to upstream. Can you elaborate?