Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1345619 > unrolled thread
| Started by | David Woodhouse <dwmw2@infradead.org> |
|---|---|
| First post | 2016-02-29 11:20 +0100 |
| Last post | 2016-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.
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
| From | David Woodhouse <dwmw2@infradead.org> |
|---|---|
| Date | 2016-02-29 11:20 +0100 |
| Subject | Re: [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]
| From | "Luis R. Rodriguez" <mcgrof@suse.com> |
|---|---|
| Date | 2016-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]
| From | James Bottomley <James.Bottomley@HansenPartnership.com> |
|---|---|
| Date | 2016-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]
| From | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| Date | 2016-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