On Thursday, December 8, 2022, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote:
> On Thursday, December 8, 2022, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx>
> wrote:
>
> > On Thu, 2022-12-08 at 12:58 +0000, Peter Robinson wrote:
> > >
> > > I've done a few passes, dropping a bunch of older firmware upstream
> > > that are no longer supported in any stable kernel release, also a
> > > bunch of de-dupe and linking of files rather than shipping of multiple
> > > copies of the same firmware. It's improved things a bit, unfortunately
> > > a lot of the dead firmware was tiny compared to say average modern
> > > devices like GPUs or WiFI.
> > >
> > > The problem with a lot of the firmware, and with the new nvidia "open
> > > driver" which shoves a lot of stuff into firmware in order to have an
> > > upstreamable driver apparently the firmwares there are going to be
> > > 30+Mb each, is that they're needed to bring up graphics/network etc to
> > > even just install so I don't know how we can get around this and still
> > > have a device work enough to be able to install the needed firmware
> > > across the network.
> > >
> > > Ideas on how to solve that problem welcome.
> >
> > Sorry if this is way off, but - do we need the GPU firmwares to run a
> > graphical install on the fallback path, just using the framebuffer set
> > up by the firmware? How crazy would it be to just do that - ship the
> > installer env with no GPU firmware?
>
>
> That would be very crazy, as you will have a degraded user experience
> (laggy UI, wrong resolution, ...) to save a couple of megabytes that are a
> non issue for today's hardware.
Please bear in mind the difference between bare metal and virtual
machines. The bare metal machine may have 32 GB of RAM, making a
800 MB install image a non-issue. For a public cloud virtual machine
though, this could bump your VM sizing up 1 level from 2 GB quota
to a 4 GB RAM quota, with correspondingly higher price point. Now
most people probably don't run the installer in a public cloud,
preferring pre-built disk images. Even in a local machine though,
you may be using most of your 32 GB of RAM for other things (well
firefox/chrome), so allowing extra for the VM is not without
resource cost. If we could figure out a way to knock a few 100 MB
off the installer RAM requirements that is valuable.
The problem I see here is not the presence of the firmware on the image, but the fact that it seems to be loaded into memory despite not being used.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of- conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/kernel@ lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
