[lowrisc-dev] Re: Handling RISC-V config-string in the Linux kernel
(Re: [sw-dev] Is a de facto standard memory map helpful or harmful?)
Robert N.M. Watson
robert.watson at cl.cam.ac.uk
Wed Jul 20 10:29:48 BST 2016
On 20 Jul 2016, at 10:22, Alex Bradbury <asb at asbradbury.org> wrote:
>> Ultimately, though, you need to convince the actors who advocate for
>> the config string. They argue that DT does not include the fields
>> needed for RISC-V and would need to be extended, anyway.
> I hadn't seen any arguments that weren't based on the FDT encoding,
> I'd certainly be interested in them.
> Although my emails might read otherwise, I'd like to be clear I'm not
> really advocating that config-string be dropped in favour of
> device-tree. My main concern is maximum compatibility with existing
> device drivers in the Linux kernel. I'd argue any new system has a
> certain complexity/weirdness budget before people start to really push
> back. I'd personally much rather spend this budget on more interesting
> user-visible features rather than something that seems more of an
> implementation detail, which is why converting config-string to
> devicetree and exposing that to the kernel seems promising as an
> approach that requires minimal driver changes.
And not just Linux — FDT is the standard handled by FreeBSD, real-time operating systems, etc. Device drivers have configuration-mechanism-specific attachment points, and a new underlying mechanism requires device drivers to be extended to support new attachment points. Failing to conform to existing de facto standards means a lot of work on the device-driver front and will substantially reduce the degree to which existing device drivers will “just work”, requiring additional validation (which will probably not happen, leading to adoption barriers as potential consumers discover things don’t work and have to debug / fix them). Regardless of the specific in-memory encoding, conforming to an identical schema would make a huge difference in avoiding this problem. That said, I do have to ask: if FDT passes muster for ARM, MIPS, various FPGA-based systems, etc, and is the industry de facto standard, I’m not convinced that not liking FDT/DTB as a format is a good reason to diverge from it — it will generate vast amounts of work and a much bumpier adoption path. It’s also worth pointing out that there is now an open community around improving and extending FDT, which could easily be engaged with to fix gaps and rough edges. Maybe there’s an exciting new contribution to be made by the RISC-V community in the system configuration story — but more likely not, and doing one’s own thing here simply becomes more work for potential adopters.
More information about the lowrisc-dev