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


Groups > linux.kernel > #1345619 > unrolled thread

Re: [RFC v2 3/7] firmware: port built-in section to linker table

Started byDavid Woodhouse <dwmw2@infradead.org>
First post2016-02-29 11:20 +0100
Last post2016-03-01 19:00 +0100
Articles 4 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC v2 3/7] firmware: port built-in section to linker table David Woodhouse <dwmw2@infradead.org> - 2016-02-29 11:20 +0100
    Re: [RFC v2 3/7] firmware: port built-in section to linker table "Luis R. Rodriguez" <mcgrof@suse.com> - 2016-02-29 20:00 +0100
    Re: [RFC v2 3/7] firmware: port built-in section to linker table James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-03-01 17:20 +0100
      Re: [RFC v2 3/7] firmware: port built-in section to linker table "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-03-01 19:00 +0100

#1345619 — Re: [RFC v2 3/7] firmware: port built-in section to linker table

FromDavid Woodhouse <dwmw2@infradead.org>
Date2016-02-29 11:20 +0100
SubjectRe: [RFC v2 3/7] firmware: port built-in section to linker table
Message-ID<r7t5M-1ES-5@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> This ports built-in firmware to use linker tables,
> this replaces the custom section solution with a
> generic solution.
> 
> This also demos the use of the .rodata (SECTION_RO)
> linker tables.
> 
> Tested with 0 built-in firmware, 1 and 2 built-in
> firmwares successfully.

I think we'd do better to rip this support out entirely. It just isn't
needed; firmware can live in an initramfs and don't even need *any*
actual running userspace support to load it from there these days, do
we?

-- 
dwmw2

[toc] | [next] | [standalone]


#1346098

From"Luis R. Rodriguez" <mcgrof@suse.com>
Date2016-02-29 20:00 +0100
Message-ID<r7Bd1-6NF-39@gated-at.bofh.it>
In reply to#1345619
On Mon, Feb 29, 2016 at 10:12:50AM +0000, David Woodhouse wrote:
> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> > This ports built-in firmware to use linker tables,
> > this replaces the custom section solution with a
> > generic solution.
> > 
> > This also demos the use of the .rodata (SECTION_RO)
> > linker tables.
> > 
> > Tested with 0 built-in firmware, 1 and 2 built-in
> > firmwares successfully.
> 
> I think we'd do better to rip this support out entirely. It just isn't
> needed; firmware can live in an initramfs and don't even need *any*
> actual running userspace support to load it from there these days, do
> we?

I think this is reasonable if and only if we really don't know of anyone
out there not able to use initramfs. I'm happy to rip it out.

  Luis

[toc] | [prev] | [next] | [standalone]


#1346730

FromJames Bottomley <James.Bottomley@HansenPartnership.com>
Date2016-03-01 17:20 +0100
Message-ID<r7VbI-31f-21@gated-at.bofh.it>
In reply to#1345619

[Multipart message — attachments visible in raw view] — view raw

On Mon, 2016-02-29 at 10:12 +0000, David Woodhouse wrote:
> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> > This ports built-in firmware to use linker tables,
> > this replaces the custom section solution with a
> > generic solution.
> > 
> > This also demos the use of the .rodata (SECTION_RO)
> > linker tables.
> > 
> > Tested with 0 built-in firmware, 1 and 2 built-in
> > firmwares successfully.
> 
> I think we'd do better to rip this support out entirely. It just 
> isn't needed; firmware can live in an initramfs and don't even need 
> *any* actual running userspace support to load it from there these 
> days, do we?

We have lots of SCSI drivers with built in firmware.  The obvious
examples are 53c700, aic7xxx and aic79xx.  For them, we actually have
the firmware compilers in tree.  The firmware model they use just isn't
amenable to the firmware loader: they're not monolithic blobs, it's a
set of firmware scripts we use to handle particular operations before
giving control back to the host, so the firmware and the driver are
very much symbiotic.

On the other hand, I don't think any of them uses firmware sections, so
it's not an argument for not ripping out this type.

James

[toc] | [prev] | [next] | [standalone]


#1346820

From"Luis R. Rodriguez" <mcgrof@kernel.org>
Date2016-03-01 19:00 +0100
Message-ID<r7WKu-3T3-13@gated-at.bofh.it>
In reply to#1346730
On Tue, Mar 01, 2016 at 08:10:24AM -0800, James Bottomley wrote:
> On Mon, 2016-02-29 at 10:12 +0000, David Woodhouse wrote:
> > On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> > > This ports built-in firmware to use linker tables,
> > > this replaces the custom section solution with a
> > > generic solution.
> > > 
> > > This also demos the use of the .rodata (SECTION_RO)
> > > linker tables.
> > > 
> > > Tested with 0 built-in firmware, 1 and 2 built-in
> > > firmwares successfully.
> > 
> > I think we'd do better to rip this support out entirely. It just 
> > isn't needed; firmware can live in an initramfs and don't even need 
> > *any* actual running userspace support to load it from there these 
> > days, do we?
> 
> We have lots of SCSI drivers with built in firmware.  The obvious
> examples are 53c700, aic7xxx and aic79xx.  For them, we actually have
> the firmware compilers in tree.  The firmware model they use just isn't
> amenable to the firmware loader: they're not monolithic blobs, it's a
> set of firmware scripts we use to handle particular operations before
> giving control back to the host, so the firmware and the driver are
> very much symbiotic.

I'm in the process of doing some other cleanups with the firmware_class
stuff so that odd requirements get supported but clean interfaces are
also not hampered by these odd requirements, so I'll take a look at
this later. If you have other oddball firmware requirements please
let me know so I can also keep in mind.

> On the other hand, I don't think any of them uses firmware sections, so
> it's not an argument for not ripping out this type.

Thanks for confirming. I'll rip this out.

  Luis

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web