[RFC] Reintroducing split packages

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all -

I'm doing the integration work for 3.17-rc1 and, as usual, there are a
ton of drivers that are typically only used for embedded devices.
Generally, I'd prefer to just disable them, but there are always a few
people who want to run openSUSE on things like tiny Atoms.

Do we want to consider moving uncommon drivers into something like
kernel-default-uncommon and save disk space on most every other
system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain typical
file systems (xfs/ext4/btrfs) and drivers for devices most commonly
offered by qemu-kvm. I understand it doesn't cover cases like device
assignment, but those are more advanced use cases in which the full
kernel-default package would be used.

The problem I'm looking to solve is "what would work well for several
major use cases?" I'd define those as typical desktop/server/notebook
hardware and KVM instances without device assignment. (Xen is a
different conversation since dom0 and domU have different requirements
WRT drivers.) The fallback for not fitting into one of the nice boxes
is just installing another package which uses as much disk space as
the old kernel package used to, so it's not a huge inconvenience.

OTOH, having multiple kernel sub-packages has been somewhat of a PITA
WRT updates and dependencies, so I thought I'd solicit opinions.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJT90a1AAoJEB57S2MheeWyvQsP/3w4RhrNsESul6jNNqiEHVuZ
yKA0IcyyJiZgJOV6qtgz2j4JWEd14o06QTX+QsL6oyE48SQi/NqH0flAoVJGGZsz
DmremRuhWUT5R2hC2rmMZgo6hZkROGqEtdTbgpb/o31vsDZK2n8dZAzz7IiTWn2W
BYG1Ixf4I2Q2J1cjGJRaSpfBGmSdCCwtSV42tIg2Ka4EMbOfdRRSUhPSobHMWPCy
MXRPCfbJ1pN6NlN5XF++kiM8H2gFEt14jPzeMO7NYpRSAPa4V/CMANBRjEEsLh6n
YNspFJCkZSLuRFOOcwgUge2gbcfUNVF4O4BZhruHHSW49aWMVuIOJtg3cM7xcYYD
qkHNXcYTZssiPIMg6o2tl2vJB1dKhAwef1l6A75V4dc1+2QZznv7cty0NZE8mVYp
3J7M4LHwvGZMC1KEe5wDsOJNwIC4Kt74i6ZgDfl3/0GquM6ODDWZOTQykKRuP8dY
/eYDfj/rItOiVXMsIxqwdq7Komk3X4kDhgaUlveXFN524Ivplq5/uspYfyB3nTCU
yRgPJHOfj3FOp1pxAloKHfgBs1cso/yUw92PwWSY/lsUN4K3YOoys25BLElIeYhX
RrrcF19hjZkkjQvzrQl/EW0RUqTPil3UAhz0KlY/ZvKEL/rlWvhC7bD2GtUaLU8k
pXuQJ99gfpVcwUHbIoZW
=Srwn
-----END PGP SIGNATURE-----

[Takashi Iwai]

At Fri, 22 Aug 2014 09:33:41 -0400,

Post by Jeff Mahoney
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all -
I'm doing the integration work for 3.17-rc1 and, as usual, there are a
ton of drivers that are typically only used for embedded devices.
Generally, I'd prefer to just disable them, but there are always a few
people who want to run openSUSE on things like tiny Atoms.
Do we want to consider moving uncommon drivers into something like
kernel-default-uncommon and save disk space on most every other
system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain typical
file systems (xfs/ext4/btrfs) and drivers for devices most commonly
offered by qemu-kvm. I understand it doesn't cover cases like device
assignment, but those are more advanced use cases in which the full
kernel-default package would be used.
The problem I'm looking to solve is "what would work well for several
major use cases?" I'd define those as typical desktop/server/notebook
hardware and KVM instances without device assignment. (Xen is a
different conversation since dom0 and domU have different requirements
WRT drivers.) The fallback for not fitting into one of the nice boxes
is just installing another package which uses as much disk space as
the old kernel package used to, so it's not a huge inconvenience.
OTOH, having multiple kernel sub-packages has been somewhat of a PITA
WRT updates and dependencies, so I thought I'd solicit opinions.

I find it OK to split if the size matters. It's a bit painful but we
know it works from the experience with SLE.

But, if we really split, how would the sizes of both packages be?
Is kernel-common significantly large?


Takashi

[Jeff Mahoney]

Post by Takashi Iwai
At Fri, 22 Aug 2014 09:33:41 -0400,

Post by Jeff Mahoney
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all -
I'm doing the integration work for 3.17-rc1 and, as usual, there are a
ton of drivers that are typically only used for embedded devices.
Generally, I'd prefer to just disable them, but there are always a few
people who want to run openSUSE on things like tiny Atoms.
Do we want to consider moving uncommon drivers into something like
kernel-default-uncommon and save disk space on most every other
system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain typical
file systems (xfs/ext4/btrfs) and drivers for devices most commonly
offered by qemu-kvm. I understand it doesn't cover cases like device
assignment, but those are more advanced use cases in which the full
kernel-default package would be used.
The problem I'm looking to solve is "what would work well for several
major use cases?" I'd define those as typical desktop/server/notebook
hardware and KVM instances without device assignment. (Xen is a
different conversation since dom0 and domU have different requirements
WRT drivers.) The fallback for not fitting into one of the nice boxes
is just installing another package which uses as much disk space as
the old kernel package used to, so it's not a huge inconvenience.
OTOH, having multiple kernel sub-packages has been somewhat of a PITA
WRT updates and dependencies, so I thought I'd solicit opinions.

I find it OK to split if the size matters. It's a bit painful but we
know it works from the experience with SLE.
But, if we really split, how would the sizes of both packages be?
Is kernel-common significantly large?

I don't actually know. I didn't want to invest the time into going
through the driver list to create the split before there was interest.

-Jeff

--
Jeff Mahoney
SUSE Labs

[Jeff Mahoney]

Post by Jeff Mahoney

Post by Takashi Iwai

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
I'm doing the integration work for 3.17-rc1 and, as usual,
there are a ton of drivers that are typically only used for
embedded devices. Generally, I'd prefer to just disable them,
but there are always a few people who want to run openSUSE on
things like tiny Atoms.
Do we want to consider moving uncommon drivers into something
like kernel-default-uncommon and save disk space on most every
other system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain
typical file systems (xfs/ext4/btrfs) and drivers for devices
most commonly offered by qemu-kvm. I understand it doesn't
cover cases like device assignment, but those are more advanced
use cases in which the full kernel-default package would be
used.
The problem I'm looking to solve is "what would work well for
several major use cases?" I'd define those as typical
desktop/server/notebook hardware and KVM instances without
device assignment. (Xen is a different conversation since dom0
and domU have different requirements WRT drivers.) The fallback
for not fitting into one of the nice boxes is just installing
another package which uses as much disk space as the old kernel
package used to, so it's not a huge inconvenience.
OTOH, having multiple kernel sub-packages has been somewhat of
a PITA WRT updates and dependencies, so I thought I'd solicit
opinions.

I find it OK to split if the size matters. It's a bit painful
but we know it works from the experience with SLE.
But, if we really split, how would the sizes of both packages
be? Is kernel-common significantly large?

I don't actually know. I didn't want to invest the time into going
through the driver list to create the split before there was
interest.

Followup:

While this might end up being a good idea generally, the SPI part of
it is a false alarm.

This upstream commit auto-selected SPI:
e4462ffc1602d9df21c00a0381dca9080474e27a
Author: Antti Palosaari <crope-***@public.gmane.org>
Date: Sat Jul 12 21:48:39 2014 -0300

[media] Kconfig: sub-driver auto-select SPI bus

Mirics MSi001 and MSi2500 drivers uses SPI bus. Due to that we need
auto-select it too.

.. where we would have had it disabled otherwise. Unfortunately, that
device is USB, not builtin, so this is going to be a painful process
for make oldconfig this time. :)

- -Jeff

- --
Jeff Mahoney
SUSE Labs

[Matwey V. Kornilov]

Post by Jeff Mahoney
Hi all -
I'm doing the integration work for 3.17-rc1 and, as usual, there are a
ton of drivers that are typically only used for embedded devices.
Generally, I'd prefer to just disable them, but there are always a few
people who want to run openSUSE on things like tiny Atoms.
Do we want to consider moving uncommon drivers into something like
kernel-default-uncommon and save disk space on most every other
system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain typical
file systems (xfs/ext4/btrfs) and drivers for devices most commonly
offered by qemu-kvm. I understand it doesn't cover cases like device
assignment, but those are more advanced use cases in which the full
kernel-default package would be used.
The problem I'm looking to solve is "what would work well for several
major use cases?" I'd define those as typical desktop/server/notebook
hardware and KVM instances without device assignment. (Xen is a
different conversation since dom0 and domU have different requirements
WRT drivers.) The fallback for not fitting into one of the nice boxes
is just installing another package which uses as much disk space as
the old kernel package used to, so it's not a huge inconvenience.
OTOH, having multiple kernel sub-packages has been somewhat of a PITA
WRT updates and dependencies, so I thought I'd solicit opinions.
-Jeff

Imagine, I have the usb device with the uncommon driver from staging/
moved far away to the separate package.
Then I plug it and found that there is no driver.
How should I know that it exists in the separate package?

[Takashi Iwai]

At Fri, 22 Aug 2014 19:09:37 +0400,

Post by Matwey V. Kornilov

Post by Jeff Mahoney
Hi all -
I'm doing the integration work for 3.17-rc1 and, as usual, there are a
ton of drivers that are typically only used for embedded devices.
Generally, I'd prefer to just disable them, but there are always a few
people who want to run openSUSE on things like tiny Atoms.
Do we want to consider moving uncommon drivers into something like
kernel-default-uncommon and save disk space on most every other
system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain typical
file systems (xfs/ext4/btrfs) and drivers for devices most commonly
offered by qemu-kvm. I understand it doesn't cover cases like device
assignment, but those are more advanced use cases in which the full
kernel-default package would be used.
The problem I'm looking to solve is "what would work well for several
major use cases?" I'd define those as typical desktop/server/notebook
hardware and KVM instances without device assignment. (Xen is a
different conversation since dom0 and domU have different requirements
WRT drivers.) The fallback for not fitting into one of the nice boxes
is just installing another package which uses as much disk space as
the old kernel package used to, so it's not a huge inconvenience.
OTOH, having multiple kernel sub-packages has been somewhat of a PITA
WRT updates and dependencies, so I thought I'd solicit opinions.
-Jeff

Imagine, I have the usb device with the uncommon driver from staging/
moved far away to the separate package.
Then I plug it and found that there is no driver.
How should I know that it exists in the separate package?

In theory, kernel-uncommon can give supplements list like KMP, so that
zypper can pick it up automatically.


Takashi

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Matwey V. Kornilov

Post by Jeff Mahoney
Hi all -
I'm doing the integration work for 3.17-rc1 and, as usual, there
are a ton of drivers that are typically only used for embedded
devices. Generally, I'd prefer to just disable them, but there
are always a few people who want to run openSUSE on things like
tiny Atoms.
Do we want to consider moving uncommon drivers into something
like kernel-default-uncommon and save disk space on most every
other system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain
typical file systems (xfs/ext4/btrfs) and drivers for devices
most commonly offered by qemu-kvm. I understand it doesn't cover
cases like device assignment, but those are more advanced use
cases in which the full kernel-default package would be used.
The problem I'm looking to solve is "what would work well for
several major use cases?" I'd define those as typical
desktop/server/notebook hardware and KVM instances without device
assignment. (Xen is a different conversation since dom0 and domU
have different requirements WRT drivers.) The fallback for not
fitting into one of the nice boxes is just installing another
package which uses as much disk space as the old kernel package
used to, so it's not a huge inconvenience.
OTOH, having multiple kernel sub-packages has been somewhat of a
PITA WRT updates and dependencies, so I thought I'd solicit
opinions.
-Jeff

Imagine, I have the usb device with the uncommon driver from
staging/ moved far away to the separate package. Then I plug it and
found that there is no driver. How should I know that it exists in
the separate package?

USB devices aren't what I had in mind since they can be plugged in
anywhere. I mean uncommon in terms of using an SoC or the like. Like
SPI, GPIO drivers, LCDs, Power Management ICs.

Or, we can make the choice to disable these drivers for the -default
kernel and use something else to enable those. I'd be ok with either
solution.

- -Jeff

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)

iQIcBAEBAgAGBQJT92RUAAoJEB57S2MheeWybTMQALQKMFjMZJ5M9UASfu0PbokF
wCjfxojGngQpIA9+9IRUsHzy061yz8G+TqtggVQ7/mvPfFiOjq7A9sy/kizEp0YI
sU19/Syte3q2ldNoB4OqGo1L4NfCabPiHLkDQY7e41a9gdqm9VTMv8+x/+QVFsK7
+Hnsc6tWh9RjU/pc5/EM1Mo7FlhmE37Qwacgd2P7Scrgt+6Fdy6A88ATUOqMJdmM
CbcE18X3aKiq9oY2BalW8t6PXlMsUBW293qzWLuXyi3afqeeEu8jRvauc+Jt8LrL
CaJz2OEM7XCsrl3DBByBnKP48YL704H/uJSNZeuzMF623Bwho4VWJgq6LswMlxGR
JeXEI+wDWtL5M8kBGZ/zauOAJcCTtivAzA94dWXz2/NvOHIE3Mgc5LQYzMyIj3Cc
BhQd67ZK+IUipf+rVBD+JOmuLAUYJQU55auDJYzU89zVATSM6yGrs2+TCwFmtdCn
Bd4b8lFIqIVcc723FgDK39yODAqi2eYxH8B+GiZ34f6TNC7UQwVrTikHjDB3dJwb
Q36efgwUOG2HmABvlhPLRAYiZ4J2XCkmF/S0dxq+7g47HiZHqoj6gwmkMf+icRcS
4ctn0OPpg8nQgv/pOySftN+fZEHY0GHLn1tP1WxgjMELjar/PqN16mLOajsp6XND
id9GktyCaV+aXnBFlJqj
=YaS3
-----END PGP SIGNATURE-----

[Andreas Färber]

Jeff,

Post by Jeff Mahoney

Post by Matwey V. Kornilov

Post by Jeff Mahoney
Hi all -
I'm doing the integration work for 3.17-rc1 and, as usual, there
are a ton of drivers that are typically only used for embedded
devices. Generally, I'd prefer to just disable them, but there
are always a few people who want to run openSUSE on things like
tiny Atoms.
Do we want to consider moving uncommon drivers into something
like kernel-default-uncommon and save disk space on most every
other system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain
typical file systems (xfs/ext4/btrfs) and drivers for devices
most commonly offered by qemu-kvm. I understand it doesn't cover
cases like device assignment, but those are more advanced use
cases in which the full kernel-default package would be used.
The problem I'm looking to solve is "what would work well for
several major use cases?" I'd define those as typical
desktop/server/notebook hardware and KVM instances without device
assignment. (Xen is a different conversation since dom0 and domU
have different requirements WRT drivers.) The fallback for not
fitting into one of the nice boxes is just installing another
package which uses as much disk space as the old kernel package
used to, so it's not a huge inconvenience.
OTOH, having multiple kernel sub-packages has been somewhat of a
PITA WRT updates and dependencies, so I thought I'd solicit
opinions.

Imagine, I have the usb device with the uncommon driver from
staging/ moved far away to the separate package. Then I plug it and
found that there is no driver. How should I know that it exists in
the separate package?

USB devices aren't what I had in mind since they can be plugged in
anywhere. I mean uncommon in terms of using an SoC or the like. Like
SPI, GPIO drivers, LCDs, Power Management ICs.
Or, we can make the choice to disable these drivers for the -default
kernel and use something else to enable those. I'd be ok with either
solution.

Could you clarify: Are you talking about x86 only or all architectures?

In the ARM world where there's little in common, save for USB devices,
such a change would make our life of building JeOS images harder.

Building more ARM flavors would be even worse, as building Kernel:HEAD
with two flavors plus obs-build is already a challenge in build time.

Regards,
Andreas

[Michal Marek]

Post by Jeff Mahoney
Do we want to consider moving uncommon drivers into something like
kernel-default-uncommon and save disk space on most every other
system? Of course, then there's also the concept of
kernel-default-base again, where it would probably contain typical
file systems (xfs/ext4/btrfs) and drivers for devices most commonly
offered by qemu-kvm. I understand it doesn't cover cases like device
assignment, but those are more advanced use cases in which the full
kernel-default package would be used.

Please keep kernel-default THE kernel package and reintroduce
kernel-default-extra for the uncommon stuff. That way, the installer can
continue to select kernel-default, and we can reuse the scripts to
generate the kernel-default-extra subpackage. Only the description needs
to be changed, because it won't be the SLE supported vs. unsupported,
but common vs. uncommon. But I think that we can keep calling the file
"supported.conf."

Michal