[Aboriginal] aboriginal changes

[Rob Landley]

On 11/12/2015 08:23 PM, Geoff Salmon wrote:
> Hi Rob
> 
> I've been experimenting with aboriginal some more. The attached patch
> adds support for applying patches held in an external directory. The
> use-case I had in mind was for things we don't want to open source yet.

Sorry for the delay, when I haven't been testing the 4.2 kernel for the
next release I'm trying to work out the design implications of your
patch. (Plus I'm traveling through california next week and need to pack
and such.)

The minor issue is a consistent naming scheme for the variables. The
"overlay" directory is basically an extra sources/root-filesystem, this
is an extra sources/patches, and the CROSS_COMPILER_PATH I added is sort
of a third extra path to something. Trying to think of a consistent
naming scheme between them that lets people know what behavior to expect
after they've learned one. (And really, PREFERRED_MIRROR is another one,
but that's a url not a path in the local filesystem, so it's already
outside the pattern.)

There's enough of these now maybe it should be consistent. Hmmm...
LOCAL? EXTRA? MY? "MY_CROSS_COMPILER=/path, MY_PATCHES=/path,
MY_ROOT_FILES=/path" sorta works. EXTRA_CROSS_COMPILER doesn't make
sense, and LOCAL_ROOT_FILES is slightly weird...  Sigh. Naming things,
cache invalidation, and off by one errors...

The other thing is that your external directory uses a subdirectory for
the patch name, and the original one uses a prefix. I'd kinda like that
to be consistent. (I'll take a stab at fixing it up myself.)

Just to confirm: you're ok with the built-in patches always being
applied before the local patches? (PREFERRED_MIRROR gets searched first
and the original stuff is a fallback, but as I said it's an oddball.
CROSS_COMPILER_PATH is currently a replacement, and providing a
directory under packages/ acts as a replacement that prevents automatic
patching. OVERLAY is applied after. Consistent semantics to go with
consistent naming would be nice, and "searched after the existing path"
is the consistent one. The change shouldn't screw up the cross compiler
path stuff as long as a toolset with the specified prefix is in the path
somewhere.)

> We can have patches in the soc_sw/aboriginal_patches/linux/ and when
> they graduate to something we want to share we can move them to
> aboriginal's jcore patch, or a separate aboriginal patch, and then as
> they are upstreamed they can be removed from aboriginal. Does that
> workflow make sense?

Sounds good to me.

> What do you think of the way I implemented it?

Comments above. I've applied it locally but haven't pushed it pending
probably renaming the variables. (Best I've come up with so far is the
MY_ prefixes.)

> I'm still not sure what to do about partial builds. Losing the ability
> to test small, uncommitted changes to the kernel without full rebuilds
> seems like too large a sacrifice.

Out-of-tree kernel builds with
INITRAMFS_SOURCE="/path/to/build/root-filesystem-sh2eb" are probably
your best bet. I need to have system-image.sh work for the sh2eb target
so open source developers have an easy way to get started, and it helps
you feed something stable to the jenkins builds, but for your local test
iterations system-image.sh is overkill.

Note: to extract the kernel config I'm using out of the build (combining
the source/baseconfig-linux and sources/targets/sh2eb LINUX_CONFIG
section, then expanding the miniconfig to full .config) do:

  cd ~/aboriginal
  more/test.sh sh2eb getconfig linux > ~/linux/sh2eb.miniconfig
  cd ~/linux
  make ARCH=sh allnoconfig KCONFIG_ALLCONFIG=sh2eb.miniconfig

(It should also be in build/native-compiler-sh2eb/usr/src/config-linux
but that's a REALLY awkward place for it and I need to think of a better
one. Problem is system-image.sh builds the kernel after the root
filesystem's been packaged up, so there's a sequencing issue. It's
fixable, I just haven't done it yet. So many rough edges to polish, even
after all these years...)

> Here's a couple random things I noticed in aboriginal that you may want
> to fix:
>
> This sed
> 
>   echo "Build stages:"
>   sed -n 's/#.*//;s at .*[.]/\([^.]*\)[.]sh.*@\1 at p' "$0" | uniq | xargs echo
> 
> in the help output of "build.sh" prints the following for me
> 
>   Build stages:
>   $STAGE
> 
> 
> The README refers to the file "configure" but it's named "config".

Added to the todo list. (I've also got the "fix armv6l" todo item which
is basically revive the kernel patch so I can tell linux that the
versatile board can take a different processor, and a pile of
documentation updates...)

Thanks,

Rob