[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    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean