Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #94685

Re: Re-designating cloud kernel

Show all headers | View raw

On Fri, Oct 30, 2026 at 12:44:52PM +0100, Bastian Blank wrote:
> > How granular do you plan on making the modules packages?
> 
> In the first step it'll just be two conflicting packages, one with all,
> one with just the virtualized stuff.
> 
> >                                                           Use cases for
> > things like filesystems and network protocols are likely going to be the
> > same across cloud and non-cloud deployments, so it might make sense to
> > have a "common" modules package that's installed by default in just
> > about all cases.
> 
> Maybe.  But for now I don't see a usecase for that.  It just saves a bit
> of space on our mirrors, but instead of bloats the Packages files and
> the dependency tree.
> 
> Fedora creates a -core package, but this is meant as standalone
> installable and contains everything for a normal current system to work.
> 
> >                   The major differences between virtualization platforms
> > is in the device models they expose to guests.  Would it be feasible to
> > offer dedicated "aws", "hyperv/azure", "gcp", etc driver packages that
> > provide hardware support for those specific environments?  Or is that
> > too much work/overhead?  The benefit of such disk space optimizations
> > can be significant when scaled across hundreds or thousands of systems.
> 
> I don't think there would be a real benefit from splitting it this far.
> We already shave 3/4 from the size of the kernel package, saving another
> 1% is IMHO not worth the hassle.
> 
> > For the record, I don't love the idea of eliminating the second kernel
> > build.  While we haven't taken advantage of this opportunity to this
> > point, it allows us to provide build-time optimizations to best tune
> > performance for specific deployment scenarios.
> 
> Noted.  I currently consider this to not have a high enough value for
> that.  The current cloud kernel config got some larger problems in how
> it tries to subtract config entries, not only add.  This work done here
> will also be folded back into what we do for the installer and reduce
> the complexity also.

Ack. This all sounds good to me.  Thanks.

noah

Back to linux.debian.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re-designating cloud kernel Bastian Blank <waldi@debian.org> - 2026-10-28 15:10 +0100
  Re: Re-designating cloud kernel Noah Meyerhans <noahm@debian.org> - 2026-10-28 15:50 +0100
    Re: Re-designating cloud kernel Noah Meyerhans <noahm@debian.org> - 2026-10-28 20:30 +0100
    Re: Re-designating cloud kernel Ross Vandegrift <rvandegrift@debian.org> - 2026-10-28 21:00 +0100
    Re: Re-designating cloud kernel Bastian Blank <waldi@debian.org> - 2026-10-30 13:10 +0100
      Re: Re-designating cloud kernel Noah Meyerhans <noahm@debian.org> - 2026-10-30 16:20 +0100

csiph-web