[uClinux-dev] [slightly OT] the proper git repo to support a processor port

[Robert P. J. Day]

  since i'm now just about at the point where i can take the nios2
stuff i've been fighting with and try to put it into a git repository
where others can get at it, i'd like to know the proper strategy for
doing that.  let me expand on that.

  as i read it, i can download a 2.6.23-compatible "big" patch from
uclinux.org here:

http://uclinux.org/pub/uClinux/uClinux-2.6.x/linux-2.6.23-uc0.patch.gz

(ASIDE:  how about bz2 format tarballs as well?  :-)

  so, with a pristine 2.6.23 kernel, i can apply that honking big
patch to get nios2 (and other) support in a 2.6.23 kernel.  two
drawbacks to that approach:

  1) i'd prefer a (smaller) patch that was nios2-specific, and
  2) that patch *definitely* is not compatible with the latest git
     pull of the kernel, as numerous things have changed between
     2.6.23 and 2.6.24-rc1.

so, purely for the entertainment value, here's what i did.

  using humongous whacks, i removed from that "big" patch anything
that clearly had nothing to do with nios2.  i was conservative about
that, though -- if i was unsure, i left it in as i can always come by
later and carefully remove more.  what i had left, of course, was
something that would still patch cleanly against 2.6.23, but no
guarantee that it would even configure or build.  no matter.  onward.

  the next goal was to take that (much smaller) patch and fix it so it
applied cleanly against the latest kernel git pull.  (note carefully
that doing that ***in no way*** guaranteed that that result would give
me a kernel tree that would build or even configure, but i figured
that, at the very least, making sure that the patch applied cleanly
would resolve a lot of future potential problems.)

  to that end, i broke my smaller, nios2-specific patch into two
parts -- what i called the "pure" part and the "impure" part, defined
thusly:

  "pure":  that part of the patch that represents only new content
added to the kernel tree that can't possibly not patch cleanly --
things like the brand new "include/asm-nios2nommu/" and
"arch/nios2nommu/" directories.  that's not to say that that content
is *correct* WRT to the latest kernel git pull, only that it can't
possibly not patch cleanly since it's not clashing with existing
content.

  "impure":  the remainder of the patch, which might have to be
tweaked to patch cleanly, since it's potentially being applied against
existing kernel content.  for example, here's the first several lines
of diffstat of my impure patch:

 drivers/char/Kconfig             |   18
 drivers/char/Makefile            |    2
 drivers/char/altera_pio_button.c |  280 +++
 drivers/char/lcd_16207.c         |  132 +
 drivers/mtd/Kconfig              |    7
 drivers/mtd/Makefile             |    1
 drivers/mtd/chips/Kconfig        |    9
 drivers/mtd/chips/Makefile       |    1
 drivers/mtd/chips/epcs.c         |  205 ++
 drivers/mtd/chips/epcs.h         |   79 +
 drivers/mtd/chips/epcs_low.c     |  486 ++++++
 drivers/mtd/maps/Kconfig         |   91 +
 drivers/mtd/maps/Makefile        |   11
 drivers/mtd/maps/altera.c        |  188 ++
 drivers/mtd/maps/epcs_map.c      |  157 ++
 drivers/mtd/maps/microtronix.c   |  129 +
 drivers/mtd/maps/uCbootmap.c     |  185 ++
 drivers/mtd/maps/uclinux.c       |   57
 drivers/mtd/mtdchar.c            |   44
 drivers/mtd/uCbootpart.c         |  129 +
 drivers/net/Kconfig              |   68
 ... blah blah blah ...

(and, again, i'm not even sure that all of that is truly necessary
but, to err on the safe side, i'll leave stuff in since i can always
toss it later.)

  and, finally, once i have that impure patch, i do the absolutely
minimal amount of work to get it to patch cleanly against the kernel
git tree, and *that's* what i want to use as my initial git repository
content -- commit 1 -- since it represents the most basic setup i can
imagine that could *possibly* work.

  note well that, just because the patches apply cleanly doesn't mean
the result will build or even configure properly.  in fact, i *know*
it won't.  but if i start there, i will at least have a git history of
what it took to get from there to a final, working situation, and i
*really* want a record of that history.  and here's where i need some
serious, git-related advice.

  once i have *my* nios2-oriented git repo, i want to be able to do
the following:

  1) update with my ongoing nios2 fixes,

  2) pull from the main kernel git repo to get kernel updates,
     possibly resolving any merge conflicts that crop up, and

  3) allow others to pull from my repo to add nios2 support to their
     kernel git clone without breaking anything else in *their* cloned
     repo.

and since i'm not a git expert, i'm open to advice on the best way to
do that.  and thoughts on whether any of this makes sense.

  comments?  have i forgotten anything?  is this the normal way that
someone creates a git repository to support a processor port?

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================