[lkml]   [2012]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] bcb: Android bootloader control block driver
    On Fri, Jun 29, 2012 at 09:56:36PM +0000, Boie, Andrew P wrote:
    > > From: NeilBrown []
    > > Sent: Friday, June 29, 2012 2:25 PM
    > >
    > > On Fri, 29 Jun 2012 12:36:30 -0700 Andrew Boie <>
    > > wrote:
    > >
    > > > Android userspace tells the kernel that it wants to boot into recovery
    > > > or some other non-default OS environment by passing a string argument
    > > > to reboot(). It is left to the OEM to hook this up to their specific
    > > > bootloader.
    > > Maybe I'm missing something obvious, but why does this need to be
    > > implemented
    > > in the kernel? Can't some user-space process just write to that partition
    > > using open/read/seek/write/close before calling 'reboot'.
    > Thanks for reviewing. The way Android is currently designed, all calls
    > to reboot the system into an alternate target go into android_reboot()
    > in libcutils which then make the reboot() system call with a string
    > argument. How this is actually done on a particular board is not
    > specified in the Android Open Source Project as far as I can see. The
    > particular bootloader is not specified either, many different ones are
    > being used in practice.

    Which is fine, the kernel doesn't, and shouldn't care about this.

    > Not every architecture is going to be using the Bootloader Control
    > Block to handle these boots into alternate targets. For example, I
    > worked on one Android-based device that didn't have a traditional
    > bootloader at all and the reboot hook in the kernel was radically
    > different. In this case the BCB ended up only being used by the
    > recovery console to stash its command line arguments.

    So what architectures are going to be using this?

    > If this were all done in userspace, then I think there would have to
    > be separate code paths in libcutils for different board
    > implementations of this policy. As of right now libcutils doesn't have
    > any hardware-specific stuff in it and the mechanism to effect these
    > policies is left to the kernel, libcutils works everywhere without
    > modification.

    So, without that, the kernel is setting the policy here instead? That's
    generally the opposite of what we want to do, it's up to userspace to
    determine things like this.


    greg k-h

     \ /
      Last update: 2012-06-30 06:01    [W:0.024 / U:1.336 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site