[opensuse-kernel] [RFC] Reintroducing split packages
-----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----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Fri, 22 Aug 2014 09:33:41 -0400, Jeff Mahoney wrote:
-----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 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri Aug 22 10:29:23 2014, Takashi Iwai wrote:
At Fri, 22 Aug 2014 09:33:41 -0400, Jeff Mahoney wrote:
-----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 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/22/14, 10:30 AM, Jeff Mahoney wrote:
On Fri Aug 22 10:29:23 2014, Takashi Iwai wrote:
At Fri, 22 Aug 2014 09:33:41 -0400, Jeff Mahoney wrote:
-----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@iki.fi> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT915dAAoJEB57S2MheeWy+ZIP/icilZW0nZWC6zn9/rBDIhpG g+S2oxCGlA2RskXKelrQm9nla9TDHUdmu1aSDNPozYAA8UMhnPYQU+OXA/oNQ2Jh emwNjRxCKN8UihdsKakbaQOcAxbuSWQ2ki3qd9F8iTHJmixhE4XJoE24PTwoC8G8 cDkGUA83U6in1UyIkTi7t2K0CsM1okrM44p08pYlUGqa0ru5bRXOSAzWlDfWfoo2 Ruk13sKjDmt3GRJJUuEyzrtkA4oMdwPUDUrkD2whxdvuhXIap+fzPKBzV3y+F7uE iqofYVa61u8IW4X/3P98TEbboeRNR+2DGBPcndP5eUah0GbIQl9jMVRo1UxMv9dd mZHuVvka3Mz++myPOcGWZOJPvH/FnBg80luBJ4zjAlAajBmAmJjR72eQuuUlOpMf ws8Z3ajuV5Jg+Ci/ewhRvnTKvcx0rTXLMOrlb8mCDuWxUescpoZYWquQYx0NSmfw CiO9NRP1XTBFD8F9xnKnbjHbaqParxzLO4v6KwkFQzFVypF+qm1e4LL0ESqhBqRI Rw3pMbaU8v17+zGFDsl1SqIix3CBIylOsrliYdCN9h6a8Ll8FhsvorS8NHk/s/Pk Pk6yRkfRtREbKYsba04Mq505cC4SsQLCTwShLh0eYbpfAlFY55VReq4zq6ZKnUA/ diSWS/Ry4QxLB0ZnvoRW =sGBU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
22.08.2014 17:33, 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? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Fri, 22 Aug 2014 19:09:37 +0400, Matwey V. Kornilov wrote:
22.08.2014 17:33, 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 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/22/14, 11:09 AM, Matwey V. Kornilov wrote:
22.08.2014 17:33, 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----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Jeff, Am 22.08.2014 17:40, schrieb Jeff Mahoney:
On 8/22/14, 11:09 AM, Matwey V. Kornilov wrote:
22.08.2014 17:33, 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 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Dne 22.8.2014 15:33, Jeff Mahoney napsal(a):
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 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (5)
-
Andreas Färber -
Jeff Mahoney -
Matwey V. Kornilov -
Michal Marek -
Takashi Iwai