lkml.org 
[lkml]   [2015]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] ARM: /proc/atags: Export also for DT
    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?


    Nicolas


    \
     
     \ /
      Last update: 2015-01-28 03:21    [W:5.113 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site