Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Josh Boyer (jwbo...@gmail.com) said: You'd want to do it something like that. kernel-minimal as you say but with a Provides: kernel, kernel-common as you say. I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. This would all be done from one kernel spec and built out at the same time. We've got a lot of new infrastructure coming for kernel builds and we don't want to make things even more complicated by having to do multiple rpm build runs. All of this can probably already be done with a new 'flavor' in the existing kernel.spec. I really wouldn't do the common/minimal split though. It just makes it more complicated for not a whole lot of gain. The idea that Dave, Justin, and Kevin all had simlutaneously about doing a 'kernel-virtguest' might be worthwhile if someone wants to spend time poking at a config, etc. That also works with the normal paradigm where all the variants provide 'kernel' for RPM dependency purposes; if you try to have a kernel-minimal that provides 'kernel' while also having a 'kernel' package that requires 'kernel-minimal', things get a bit more strange. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Thu, Oct 18, 2012 at 10:33:27AM -0400, Bill Nottingham wrote: All of this can probably already be done with a new 'flavor' in the existing kernel.spec. I really wouldn't do the common/minimal split though. It just makes it more complicated for not a whole lot of gain. The idea that Dave, Justin, and Kevin all had simlutaneously about doing a 'kernel-virtguest' might be worthwhile if someone wants to spend time poking at a config, etc. That also works with the normal paradigm where all the variants provide 'kernel' for RPM dependency purposes; if you try to have a kernel-minimal that provides 'kernel' while also having a 'kernel' package that requires 'kernel-minimal', things get a bit more strange. I'm open to this idea, but I think it's nicer if one can go from the reduced selection to the full just by adding in the right package, not changing or removing things. Unlike PAE or etc., I don't think we'd actually build anything differently (would we?). -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Thu, Oct 18, 2012 at 10:39 AM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Oct 18, 2012 at 10:33:27AM -0400, Bill Nottingham wrote: All of this can probably already be done with a new 'flavor' in the existing kernel.spec. I really wouldn't do the common/minimal split though. It just makes it more complicated for not a whole lot of gain. The idea that Dave, Justin, and Kevin all had simlutaneously about doing a 'kernel-virtguest' might be worthwhile if someone wants to spend time poking at a config, etc. That also works with the normal paradigm where all the variants provide 'kernel' for RPM dependency purposes; if you try to have a kernel-minimal that provides 'kernel' while also having a 'kernel' package that requires 'kernel-minimal', things get a bit more strange. I'm open to this idea, but I think it's nicer if one can go from the reduced selection to the full just by adding in the right package, not changing or removing things. Unlike PAE or etc., I don't think we'd actually build anything differently (would we?). Of course we would. The entire point is to reduce the size, and the only way to reduce the size is to build it with different config options. And we're not talking about going from kernel-virtguest to kernel by installing kernel-everythingnotinvirtguest. That's still going down the split the kernel up into a bunch of subpackages route which just creates more work for the maintainers. At the moment though, all of this is just talk anyway. If something like this is to happen, someone actually has to do work. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Thu, Oct 18, 2012 at 10:44:58AM -0400, Josh Boyer wrote: I'm open to this idea, but I think it's nicer if one can go from the reduced selection to the full just by adding in the right package, not changing or removing things. Unlike PAE or etc., I don't think we'd actually build anything differently (would we?). Of course we would. The entire point is to reduce the size, and the only way to reduce the size is to build it with different config options. And we're not talking about going from kernel-virtguest to kernel by installing kernel-everythingnotinvirtguest. That's still going down the split the kernel up into a bunch of subpackages route which just creates more work for the maintainers. We already have kernel-modules-extra. I think the idea would be to add kernel-modules-virt and kernel-modules-normal to that, at most. (Or, put the virt modules in kernel, and just add one more subpackage, kernel-modules-normal.) There's already code in the spec file for dealing with modules-extra, so it's mostly a matter of extending that slightly -- not doing something entirely new, *and* not going down the alarmist slope of a horde of subpackages. At the moment though, all of this is just talk anyway. If something like this is to happen, someone actually has to do work. Start with an idea, discuss it, come up with a plan, find resources for that plan, and then implement. Sometimes things happen the other way around, but only when we happen to be lucky, and it often has consequences like extra ongoing work with no support. So, just talk is an important place to start. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Thu, Oct 18, 2012 at 11:34:00AM -0400, Josh Boyer wrote: On Thu, Oct 18, 2012 at 11:15 AM, Matthew Miller mat...@fedoraproject.org wrote: On Thu, Oct 18, 2012 at 10:44:58AM -0400, Josh Boyer wrote: At the moment though, all of this is just talk anyway. If something like this is to happen, someone actually has to do work. Start with an idea, discuss it, come up with a plan, find resources for that plan, and then implement. Sometimes things happen the other way around, but only when we happen to be lucky, and it often has consequences like extra ongoing work with no support. So, just talk is an important place to start. OK. So here's a more blunt response. I'm really against splitting the modules up into more subpackages, regardless of how many it is. I will not spend any time looking at how to do that. I won't spend time discussing further plans to do something I don't feel is maintainable. If you find someone willing to, great. Post patches to the kernel list and we'll review them. But I'm telling you now that it will be an uphill battle. Just to be clear on this, if someone feels it is worthwhile and wants to step up and do the work, it can't just be someone who will send patches to change the current kernel and leave. It has to be someone willing to sign up to maintain the solution in the rawhide kernel. Modules change, get added or removed, and/or have deps change pretty much every single release. 3.7 just moved the nat modules. This is why we are saying that it is much easier to do a different build of another flavor than to split out the modules into more subpackages. Justin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Thu, Oct 18, 2012 at 10:56:21AM -0500, Justin M. Forbes wrote: I'm really against splitting the modules up into more subpackages, regardless of how many it is. I will not spend any time looking at how to do that. I won't spend time discussing further plans to do something I don't feel is maintainable. If you find someone willing to, great. Post patches to the kernel list and we'll review them. But I'm telling you now that it will be an uphill battle. Just to be clear on this, if someone feels it is worthwhile and wants to step up and do the work, it can't just be someone who will send patches to change the current kernel and leave. It has to be someone willing to sign up to maintain the solution in the rawhide kernel. Modules change, get added or removed, and/or have deps change pretty much every single release. 3.7 just moved the nat modules. This is why we are saying that it is much easier to do a different build of another flavor than to split out the modules into more subpackages. Head nods to both of you. I'm happy to live in reality rather than utopia and this is helpful feedback. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Tue, Oct 16, 2012 at 9:07 AM, Bill Nottingham nott...@redhat.com wrote: Peter Robinson (pbrobin...@gmail.com) said: I wonder... could we make linux-firmware optional? I would expect many virt env's don't need any firmware to work... (but of course I could be wrong). It use to be optional, I know on the olpc xo-1 it use to be optional and there should be no firmware needed for an average VM. I'd also love to see it broken down for various profiles because most desktops don't need enterprise storage controllers, most servers don't need wifi and most ARM platforms don't need most of the stuff in there but do need a few ARM only firmware packages. However, if you go down that route, the kernel should be the same way, the firmware should be separate subpackages, and requires should be done at the module - firmware level by generating it from the MODULE_FIRMWARE tags. (Unless you're relying on packagekit to install your firmware, which if you're going that minimal seems to have missed the forest for the trees somewhere.) I'm not understanding what you're proposing. Are you suggesting: 1) We have further split up module sub-packages that carry their own firmware requires (e.g. kernel-module-iwlwifi requires iwlwifi-firmware) or 2) Even more firmware subpackages split out of linux-firmware. If you're suggesting 1, I'd be really really opposed to that. It would make packaging in kernel.spec even more of a nightmare than it already is. If you're suggesting 2, I don't see the point. The kernel will install and even with per-module dependencies generated (somehow), it'll still install all of the various -firmware packages because the modules will be getting installed. Or maybe you mean something else, and my jet-lagged and coffee deprived brain just isn't following. I actually hope this is the case, because neither of the above 2 options sound that great to me... josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Josh Boyer (jwbo...@gmail.com) said: However, if you go down that route, the kernel should be the same way, the firmware should be separate subpackages, and requires should be done at the module - firmware level by generating it from the MODULE_FIRMWARE tags. (Unless you're relying on packagekit to install your firmware, which if you're going that minimal seems to have missed the forest for the trees somewhere.) I'm not understanding what you're proposing. Are you suggesting: 1) We have further split up module sub-packages that carry their own firmware requires (e.g. kernel-module-iwlwifi requires iwlwifi-firmware) or 2) Even more firmware subpackages split out of linux-firmware. If you're suggesting 1, I'd be really really opposed to that. It would make packaging in kernel.spec even more of a nightmare than it already is. If you're suggesting 2, I don't see the point. The kernel will install and even with per-module dependencies generated (somehow), it'll still install all of the various -firmware packages because the modules will be getting installed. Both - if people want firmware packages split out of linux-firmware, it doesn't make sense unless the drivers (similar in size) are also split, and if you were to do so, you'd need to start adding the driver - firmware package dependency mapping. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote: If you're suggesting 1, I'd be really really opposed to that. It would make packaging in kernel.spec even more of a nightmare than it already is. [...] Both - if people want firmware packages split out of linux-firmware, it doesn't make sense unless the drivers (similar in size) are also split, and if you were to do so, you'd need to start adding the driver - firmware package dependency mapping. Basically: it's hard, but the only way we're going to get to a reasonably-small minimal image, so if that's important (and I believe it is), it's something Fedora should invest resources in. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 10:51 AM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote: If you're suggesting 1, I'd be really really opposed to that. It would make packaging in kernel.spec even more of a nightmare than it already is. [...] Both - if people want firmware packages split out of linux-firmware, it doesn't make sense unless the drivers (similar in size) are also split, and if you were to do so, you'd need to start adding the driver - firmware package dependency mapping. What the hell did you drink today, Bill? Basically what you're suggesting is that Fedora move to a kmod model for everything. Which means you'd have to install all of them by default anyway or the kernel team would be swamped with bugs like I installed Fedora and my random USB device doesn't work! Seriously, no. There are 3 kernel people. There's no way we have time to sit around closing bugs with stuff like Install kernel-module-foo. Basically: it's hard, but the only way we're going to get to a reasonably-small minimal image, so if that's important (and I believe it is), it's something Fedora should invest resources in. No. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 4:51 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Oct 17, 2012 at 10:47:34AM -0400, Bill Nottingham wrote: If you're suggesting 1, I'd be really really opposed to that. It would make packaging in kernel.spec even more of a nightmare than it already is. [...] Both - if people want firmware packages split out of linux-firmware, it doesn't make sense unless the drivers (similar in size) are also split, and if you were to do so, you'd need to start adding the driver - firmware package dependency mapping. Basically: it's hard, it is a mess. but the only way we're going to get to a reasonably-small minimal image, not true. so if that's important (and I believe it is), I believe it isn't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: Basically: it's hard, it is a mess. but the only way we're going to get to a reasonably-small minimal image, not true. Given that the kernel is currently a full quarter of the current image, I think it has to be. so if that's important (and I believe it is), I believe it isn't. And that's fine. We'll need to come to a group decision eventually but we don't need to right now. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 11:37:29AM -0400, Josh Boyer wrote: What the hell did you drink today, Bill? Basically what you're suggesting is that Fedora move to a kmod model for everything. Which means you'd have to install all of them by default anyway or the kernel team would be swamped with bugs like I installed Fedora and my random USB device doesn't work! The default desktop case would pull in everything, I think. Splitting it up would be not just for fun but in order to target smaller cloud and virt images. Because we can reasonably define the targets there, it doesn't need to be completely all-out kmod model for everything approach at all. Seriously, no. There are 3 kernel people. There's no way we have time to sit around closing bugs with stuff like Install kernel-module-foo. Yeah; it is reasonable to say that we can't do this without more resources. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: Basically: it's hard, it is a mess. but the only way we're going to get to a reasonably-small minimal image, not true. Given that the kernel is currently a full quarter of the current image, I think it has to be. No you could also use a different kernel image; build your own kernel; use a compressed filesystem, don't use a kernel at all and some container based approach instead of full virt for your cloud instances (you could even base them on a btrfs subvolume and save more space that way). Outside of the cloud use case the disk space added by modules and firmware does not matter a bit (so I am ignoring this cases). So there are lots of other ways to achieve what you want without splitting the kernel into hundreds of sub packages. So while it is a way it is not the only way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: Given that the kernel is currently a full quarter of the current image, I think it has to be. No you could also use a different kernel image; build your own kernel; use a compressed filesystem, don't use a kernel at all and some container based approach instead of full virt for your cloud instances (you could even base them on a btrfs subvolume and save more space that way). Outside of the cloud use case the disk space added by modules and firmware does not matter a bit (so I am ignoring this cases). So there are lots of other ways to achieve what you want without splitting the kernel into hundreds of sub packages. So while it is a way it is not the only way. As reluctant as I am to introduce new kernel packages, an ultra-minimal kernel package for use in cloud environments may make more sense than splitting up the one-size-fits-all packages into hundreds of sub-packages. But even this option is a lot of work, and isn't a panacea. With virtualised environments supporting pci/usb passthrough, where do you draw the line on what hardware to support in a hypothetical kernel-cloud package ? Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: Basically: it's hard, it is a mess. but the only way we're going to get to a reasonably-small minimal image, not true. Given that the kernel is currently a full quarter of the current image, I think it has to be. No you could also use a different kernel image; build your own kernel; [I'll treat these two the same, because they amount to the same thing] It's a considerable amount of work for everyone if people building minimal images have to use a different kernel. By using the same kernel as everyone else, it means that bug reports against the normal kernel package are relevant, and it means that the regular kernel gets more testing. Also it's a lot of work to compile another kernel, when we've already got a team of (apparently 3) people doing this. use a compressed filesystem, Every minimal image I've ever seen has been compressed to the max. don't use a kernel at all and some container based approach instead of full virt for your cloud instances Unfortunately containers don't work for every application out there. Obviously *if* you can use a container, then you should, and you probably are already. Outside of the cloud use case the disk space added by modules and firmware does not matter a bit (so I am ignoring this cases). It's partly disk space, it's more often the time taken to copy these images over the network (eg. when users download minimal images, or when they are PXE-booted). So there are lots of other ways to achieve what you want without splitting the kernel into hundreds of sub packages. I don't think we're talking hundreds of sub packages. Most people seem to be discussing a split into between 2 and 5 packages. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: Basically: it's hard, it is a mess. but the only way we're going to get to a reasonably-small minimal image, not true. Given that the kernel is currently a full quarter of the current image, I think it has to be. No you could also use a different kernel image; build your own kernel; [I'll treat these two the same, because they amount to the same thing] No the one means we ship a kernel-foo (like kernel-minimal or whatever we call it) and the other is you build your own kernel. It's a considerable amount of work for everyone if people building minimal images have to use a different kernel. If it is all about using kernel-minimal (or whatever it is called) instead of kernel there is no extra work for the ones that build minimal images at all. By using the same kernel as everyone else, it means that bug reports against the normal kernel package are relevant, and it means that the regular kernel gets more testing. They can be built from the same srpm (same version, same patches applied just some modules stripped). Also it's a lot of work to compile another kernel, when we've already got a team of (apparently 3) people doing this. I'd argue it is less work then building a subpackage for every kernel module. use a compressed filesystem, Every minimal image I've ever seen has been compressed to the max. The image itself might be the installed system isn't ... which is the think I was talking about (i.e this would allow you to save disk space after installation). The smaller image would just save bandwidth for the initial download and/or space on mirrors. don't use a kernel at all and some container based approach instead of full virt for your cloud instances Unfortunately containers don't work for every application out there. Obviously *if* you can use a container, then you should, and you probably are already. That might be true but I can't think of such applications right now. Couldn't the applications you have in mind be modified / fixed to work in such an environment? Outside of the cloud use case the disk space added by modules and firmware does not matter a bit (so I am ignoring this cases). It's partly disk space, it's more often the time taken to copy these images over the network (eg. when users download minimal images, or when they are PXE-booted). In that case you should place the image on your internal network. I doubt anyone uses a cloud infrastructure where you download the images over the internet using a 56k modem. So there are lots of other ways to achieve what you want without splitting the kernel into hundreds of sub packages. I don't think we're talking hundreds of sub packages. Most people seem to be discussing a split into between 2 and 5 packages. People where talking about splitting each module (driver) into its own package. This are far more then 5. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 6:34 PM, drago01 drag...@gmail.com wrote: On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote: On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller mat...@fedoraproject.org wrote: On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote: Basically: it's hard, it is a mess. but the only way we're going to get to a reasonably-small minimal image, not true. Given that the kernel is currently a full quarter of the current image, I think it has to be. No you could also use a different kernel image; build your own kernel; [I'll treat these two the same, because they amount to the same thing] No the one means we ship a kernel-foo (like kernel-minimal or whatever we call it) and the other is you build your own kernel. It's a considerable amount of work for everyone if people building minimal images have to use a different kernel. If it is all about using kernel-minimal (or whatever it is called) instead of kernel there is no extra work for the ones that build minimal images at all. By using the same kernel as everyone else, it means that bug reports against the normal kernel package are relevant, and it means that the regular kernel gets more testing. They can be built from the same srpm (same version, same patches applied just some modules stripped). Also it's a lot of work to compile another kernel, when we've already got a team of (apparently 3) people doing this. I'd argue it is less work then building a subpackage for every kernel module. use a compressed filesystem, Every minimal image I've ever seen has been compressed to the max. The image itself might be the installed system isn't ... which is the think I was talking about (i.e this would allow you to save disk space after installation). The smaller image would just save bandwidth for the initial download and/or space on mirrors. don't use a kernel at all and some container based approach instead of full virt for your cloud instances Unfortunately containers don't work for every application out there. Obviously *if* you can use a container, then you should, and you probably are already. That might be true but I can't think of such applications right now. Couldn't the applications you have in mind be modified / fixed to work in such an environment? Outside of the cloud use case the disk space added by modules and firmware does not matter a bit (so I am ignoring this cases). It's partly disk space, it's more often the time taken to copy these images over the network (eg. when users download minimal images, or when they are PXE-booted). In that case you should place the image on your internal network. I doubt anyone uses a cloud infrastructure where you download the images over the internet using a 56k modem. So there are lots of other ways to achieve what you want without splitting the kernel into hundreds of sub packages. I don't think we're talking hundreds of sub packages. Most people seem to be discussing a split into between 2 and 5 packages. People where talking about splitting each module (driver) into its own package. This are far more then 5. Not necessarily, I was the person wanting it split down and only to groups of packages like usb for usb devices, arm for arm only firmware, storage for enterprise storage, wifi etc. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 07:34:22PM +0200, drago01 wrote: If it is all about using kernel-minimal (or whatever it is called) instead of kernel there is no extra work for the ones that build minimal images at all. It really depends on what 'kernel-minimal' is. If it's the same kernel (identical vmlinuz) with groups of modules, then I'm assuming this is the same as what everyone else is proposing. But more dangerous if this is a recompile of the kernel (maybe same source, different configs). Then inevitably we're testing different codepaths. [...] Unfortunately containers don't work for every application out there. Obviously *if* you can use a container, then you should, and you probably are already. That might be true but I can't think of such applications right now. Couldn't the applications you have in mind be modified / fixed to work in such an environment? LXC isn't a secure alternative to full virtualization -- try poking random /sys files on your container -- and even now OpenVZ isn't quite upstream. Also clouds are existing ecosystems. For example I can't call up Amazon and ask that they reimplement their service on top of LXC instead of Xen. In that case you should place the image on your internal network. Well, no. I don't colocate with everyone who might want to download a minimal image. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Once upon a time, Richard W.M. Jones rjo...@redhat.com said: It really depends on what 'kernel-minimal' is. If it's the same kernel (identical vmlinuz) with groups of modules, then I'm assuming this is the same as what everyone else is proposing. I would think the only sane way would be to just change the packaing, not actually build multiple kernels (or even multiple packages with kernels). For example, a kernel-minimal that has the kernel and the core modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, network support like ipv6 and iptables, and virtio-type drivers), a kernel-common that has the rest of the current contents of kernel (and probably obsoletes kernel), and then the current kernel-modules-extras. There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On 10/17/2012 11:32 AM, Chris Adams wrote: I would think the only sane way would be to just change the packaing, not actually build multiple kernels (or even multiple packages with kernels). For example, a kernel-minimal that has the kernel and the core modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, network support like ipv6 and iptables, and virtio-type drivers), a kernel-common that has the rest of the current contents of kernel (and probably obsoletes kernel), and then the current kernel-modules-extras. There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. You'd want to do it something like that. kernel-minimal as you say but with a Provides: kernel, kernel-common as you say. I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. This would all be done from one kernel spec and built out at the same time. We've got a lot of new infrastructure coming for kernel builds and we don't want to make things even more complicated by having to do multiple rpm build runs. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 01:32:23PM -0500, Chris Adams wrote: There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. That's why I suggest defining the specific targets (for example, EC2, KVM) for the core package. The requirements may grow and change slightly, but in general it provides a simple test, with no fighting needed. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 11:38:13AM -0700, Jesse Keating wrote: I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. +1 to this -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, 17 Oct 2012 14:40:39 -0400 Matthew Miller mat...@fedoraproject.org wrote: On Wed, Oct 17, 2012 at 11:38:13AM -0700, Jesse Keating wrote: I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. +1 to this I think we should really avoid calling this minimal as we have seen that means different things to different folks. if someone wanted to explore this route, I would say call it 'kernel-virt-guest' or something similar. Establish exactly what virt env's are targeted by it, do some test runs to show that it helps anyone at all, and then sell it to the kernel maintainers. ;) Sounds like it could be a nice f19 feature if there are folks interested enough to work on it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Am 17.10.2012 18:52, schrieb Dave Jones: With virtualised environments supporting pci/usb passthrough, where do you draw the line on what hardware to support in a hypothetical kernel-cloud package ? with vmxnet3, vmw_pvscsi, vmw_balloon to support vSphere (all included in the upstream kernel) and the drivers for basic KVM guests + all the iptabales (nat, conntrack, rectent, multiport..) you are sipporting a really wide range of minimized-size and full functional setups 99 out of 100 doe snot passthru physical hardware signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, 2012-10-17 at 11:38 -0700, Jesse Keating wrote: On 10/17/2012 11:32 AM, Chris Adams wrote: I would think the only sane way would be to just change the packaing, not actually build multiple kernels (or even multiple packages with kernels). For example, a kernel-minimal that has the kernel and the core modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, network support like ipv6 and iptables, and virtio-type drivers), a kernel-common that has the rest of the current contents of kernel (and probably obsoletes kernel), and then the current kernel-modules-extras. There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. You'd want to do it something like that. kernel-minimal as you say but with a Provides: kernel, kernel-common as you say. I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. This would all be done from one kernel spec and built out at the same time. We've got a lot of new infrastructure coming for kernel builds and we don't want to make things even more complicated by having to do multiple rpm build runs. Random worry about this: would this work OK with yum's keep the last 3 kernels around functionality? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On 10/17/2012 01:46 PM, David Malcolm wrote: Random worry about this: would this work OK with yum's keep the last 3 kernels around functionality? That's obviously something that would have to be tested if this is attempted. I'm not signing up for this work, I was just making a suggestion on how to structure the rpms that fell out of the kernel spec. -- Jesse Keating Fedora -- Freedom² is a feature! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 2:38 PM, Jesse Keating jkeat...@redhat.com wrote: On 10/17/2012 11:32 AM, Chris Adams wrote: I would think the only sane way would be to just change the packaing, not actually build multiple kernels (or even multiple packages with kernels). We already build multiple kernels. All from the same source, but still multiple kernels with different config options. E.g. PAE, debug, etc. For example, a kernel-minimal that has the kernel and the core modules loaded in most installs (e.g. filesystems like ext4 and NFS, dm, network support like ipv6 and iptables, and virtio-type drivers), a kernel-common that has the rest of the current contents of kernel (and probably obsoletes kernel), and then the current kernel-modules-extras. There will always be requests to move modules from -common to -minimal, and it shouldn't be a big fight (I would bet most requests would be pretty obvious). That already exists some for -modules-extras. You'd want to do it something like that. kernel-minimal as you say but with a Provides: kernel, kernel-common as you say. I'd introduce a third metapackage just kernel that requires both of those and implicitly Provides: kernel. Most people would just get the kernel metapackage when a transaction asks for something to provide kernel, but if you explicitly ask for kernel-minimal you'd get just the minimal. This would all be done from one kernel spec and built out at the same time. We've got a lot of new infrastructure coming for kernel builds and we don't want to make things even more complicated by having to do multiple rpm build runs. All of this can probably already be done with a new 'flavor' in the existing kernel.spec. I really wouldn't do the common/minimal split though. It just makes it more complicated for not a whole lot of gain. The idea that Dave, Justin, and Kevin all had simlutaneously about doing a 'kernel-virtguest' might be worthwhile if someone wants to spend time poking at a config, etc. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Wed, Oct 17, 2012 at 3:43 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 17.10.2012 18:52, schrieb Dave Jones: With virtualised environments supporting pci/usb passthrough, where do you draw the line on what hardware to support in a hypothetical kernel-cloud package ? with vmxnet3, vmw_pvscsi, vmw_balloon to support vSphere (all included in the upstream kernel) and the drivers for basic KVM guests + all the iptabales (nat, conntrack, rectent, multiport..) you are sipporting a really wide range of minimized-size and full functional setups And xen and whatever it needs. I mean, if you're targeting virt and cloud, then you can't ignore EC2 and that is all xen. And hyper-v. Can't exclude them either. And whatever Rusty's virt thing is. And on and on. About the only virt/cloud thing you can exclude is e.g. virtualbox and that's only because they're not in the upstream kernel. Maybe one day they'll realize the error of their ways and then you have to include that too. 99 out of 100 doe snot passthru physical hardware Maybe today, but it's an ever increasing target. I don't think it can be entirely dismissed. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
Peter Robinson (pbrobin...@gmail.com) said: I wonder... could we make linux-firmware optional? I would expect many virt env's don't need any firmware to work... (but of course I could be wrong). It use to be optional, I know on the olpc xo-1 it use to be optional and there should be no firmware needed for an average VM. I'd also love to see it broken down for various profiles because most desktops don't need enterprise storage controllers, most servers don't need wifi and most ARM platforms don't need most of the stuff in there but do need a few ARM only firmware packages. However, if you go down that route, the kernel should be the same way, the firmware should be separate subpackages, and requires should be done at the module - firmware level by generating it from the MODULE_FIRMWARE tags. (Unless you're relying on packagekit to install your firmware, which if you're going that minimal seems to have missed the forest for the trees somewhere.) I wouldn't be against that, but I also don't have the time to look at that right now. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
On Tue, Oct 16, 2012 at 09:07:56AM -0400, Bill Nottingham wrote: I wonder... could we make linux-firmware optional? However, if you go down that route, the kernel should be the same way, the firmware should be separate subpackages, and requires should be done at the module - firmware level by generating it from the MODULE_FIRMWARE tags. [...] I wouldn't be against that, but I also don't have the time to look at that right now. I think this would be an excellent candidate for the Features process (and maybe F19 or F20). -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
