From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Luis R. Rodriguez" Subject: Re: [RFC v2 3/7] firmware: port built-in section to linker table Date: Fri, 29 Apr 2016 12:24:36 -0700 Message-ID: References: <1455889559-9428-1-git-send-email-mcgrof@kernel.org> <1455889559-9428-4-git-send-email-mcgrof@kernel.org> <1456740770.4666.366.camel@infradead.org> <1456848624.2369.9.camel@HansenPartnership.com> <20160301175453.GE25240@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20160301175453.GE25240@wotan.suse.de> Sender: linux-arch-owner@vger.kernel.org To: James Bottomley , Kees Cook Cc: David Woodhouse , "Luis R. Rodriguez" , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , "linux-kernel@vger.kernel.org" , Andy Lutomirski , Boris Ostrovsky , Rusty Russell , David Vrabel , Konrad Rzeszutek Wilk , Michael Brown , Juergen Gross , Ming Lei , Greg Kroah-Hartman , Arnd Bergmann , linux-arch@vger.kernel.org, Russell King , Benjamin Herrenschmidt , jbaron@akamai.com, ananth@in.ibm.com, anil.s.keshavamurthy@int List-Id: xen-devel@lists.xenproject.org On Tue, Mar 1, 2016 at 9:54 AM, Luis R. Rodriguez wrote: > 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. Just a heads up, I've put the removal through 0-day without issues, I'll be folding the removal into another series of changes for the firmware API which should help compartmentalize the user mode helper stuff as well. Luis