Re: [PATCH] ARM: /proc/atags: Export also for DT

[Jean-Christophe PLAGNIOL-VILLARD]

> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote:
> 
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
>> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
>>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
>>>> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
>>>> and let the kernel deal with it in a much saner environment than the
>>>> restricted decompressor environment.
>>> 
>>> ... which would be a step backward in the context of the transition to 
>>> DT we accepted.  People will have even less of an incentive to fix their 
>>> stuff.
>> 
>> Where's the people fixing their stuff today?
> 
> At least some people in this thread are, otherwise they'd still be away 
> hacking on their own.
> 
>> I think your position is something of an idealist rather than a 
>> realist - the reality is that five years down the line of DT, the 
>> platforms which have not converted are now *never* going to convert, 
>> irrespective of how much "incentive" we may think we should apply to 
>> the situation.
> 
> Don't get me wrong.  I'm not expecting those platforms to do native DT 
> booting ever.  However "faking" DT booting with already proven solutions 
> that don't bastardize the kernel further should be encouraged.
> 
>>> If there is indeed a sizable following for the device then someone 
>>> should figure out how to cope with upstream kernels, either through the 
>>> installation of some intermediate bootloader that can talk FDT directly, 
>>> or via a shim layer.  None of that has to be performed by nor linked 
>>> with the kernel binary, nor maintained in the kernel tree. And it's not 
>>> even that hard to do: we have precedents on other platforms with crappy 
>>> bootloaders where this just works.
>> 
>> That's a rediculous position if you want something which "just works"
>> on as much hardware as possible, which is, after all, what the single
>> zImage project is all about.
> 
> Agreed.
> 
>> To be pro single-zImage, and anti popular hardware is quite contradictory.
> 
> Indeed.  I'm not against popular hardware.
> 
>> You only have to look at x86 for this: just because ACPI came along does
>> not mean that the Linux kernel started demanding that ACPI is the only
>> way to describe the world.  Linux continues to directly support all the
>> old boot protocols that it did since the days of i386, such as the e820
>> memory interface and doesn't convert these to an ACPI table just because
>> it can.
> 
> Booting from a floppy boot sector is no longer supported though.
> 
> But that's besides the point.  If someone needs a 5-line addition to 
> atags_to_fdt.c in order to boot some old stuff then let's just do it and 
> move on. I'll happily ACK the patch. The code is there and it is not 
> going away soon.
> 
> However, if something more involved is needed, is platform specific and 
> is likely to require about as many lines in the kernel than it would 
> need in some externat shim then the shim solution should be encouraged 
> instead.  After all that's why LILO, Syslinux and Grub were created on 
> X86: to Supplement the crappy PC BIOS boot interface.  And if the 
> hardware is popular, then finding a motivated hacker to do it shouldn't 
> be too hard, right?
> 
> In other words, what prevents someone from creating, say, a custom 
> minimal Barebox version that sits on top of the existing N900 
> bootloader?  Wouldn't that provide a much better user experience?

I do agree with Nicolas

If I can get my hand on a phone Iâll put barebox on it

Best Regards,
J.
> 
> 
> Nicolas
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/