How to develop against linux-next
How to develop against linux-next
Posted Jul 9, 2008 15:16 UTC (Wed) by jejb (subscriber, #6654)In reply to: The current development kernel is...linux-next? by iabervon
Parent article: The current development kernel is...linux-next?
I assume from your comments that you're using git not quilt? (since quilt doesn't really care if you change the tree under it, you just do a quilt pop -a; install new tree; quilt push -a) The way to develop against linux-next in git is to use git rebase --onto to move your patches as linux-next changes. So, assume you have a git tree with your patches on the master branch. You also need to record the base of your branch with either a tag or a branch (you do this before you start adding patches) so that git format-patch base produces exactly all the patches you're managing. The way I set this up is to clone a tree (git clone <tree>) record the base (git branch base) and simply develop committing along the way. Now set up remote tracking branches (I tend to do one for linux-next and one for linus as): git remote add -t master -f linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git git remote add -t master -f next git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git The point of keeping the linus tree is that eventually all the branches that comprise next are merged into linus, at which point your patches will be ready for submission against vanilla linus. To download the current trees of the day, simply do a git remote update and to put your patches onto the current linux-next do git rebase --onto remotes/next/master base If this is successfully completed, you need to record the fact that you've moved the base of your patches: git branch -M base remotes/next/master You can keep doing this as many times as linux-next updates. If you think you're ready to try to place your patches onto vanilla linus, just repeat the recipe but with remotes/linus/master instead of remotes/next/master. If your attempt to rebase onto linus fails (usually because of missing commits that were in linux-next that you're relying on) simply do git rebase --abort.
Posted Jul 9, 2008 17:44 UTC (Wed)
by iabervon (subscriber, #722)
[Link] (1 responses)
Posted Jul 9, 2008 19:14 UTC (Wed)
by jejb (subscriber, #6654)
[Link]
Posted Nov 13, 2011 18:50 UTC (Sun)
by cheako (guest, #81350)
[Link] (1 responses)
What tree should be cloned? Does one clone linux-next and then configure it as a remote?
What's the reason for "git branch base" prior to configuring the remotes?
Reading the help files is confusing, I belief I'll only learn via experience.
# git2.kernel.org
Must have sent null byte first?
Posted Nov 13, 2011 20:46 UTC (Sun)
by cheako (guest, #81350)
[Link]
Posted Nov 13, 2011 20:43 UTC (Sun)
by cheako (guest, #81350)
[Link]
1. git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Posted Nov 13, 2011 20:56 UTC (Sun)
by cheako (guest, #81350)
[Link]
How to develop against linux-next
The problem isn't that developing against a rebasing tree is too difficult, because it's
generally not too hard to update things. The problem is that developing against a rebasing
tree generates a repository which isn't suitable for inclusion in the rebasing tree. That is,
following your instructions would be fine if -next weren't a useful tree to try to get your
stuff into, but the resulting repository isn't something that Stephen can pull into -next.
I suppose if you're targeting 2.6.n+3 (or later) for inclusion, you could develop against
-next, but that's sort of pessimistic. And I think that, if it makes sense to publish your
changes at all, it makes sense to have them in a state where they go against vanilla linus.
Also note that, if you develop against -next, either it doesn't matter, because you don't have
any interactions with other people's changes, or you're going to waste a lot of time when a
tree that you interact with gets some conflict and Stephen drops it (requiring you to resolve
a slew of conflicts) and then picks it up again the next day (requiring you to resolve the
same slew of conflicts the other way, back to essentially the state you had before). And that
applies to quilt as well; quilt will happily let the base change under it, but you'll have
days when your code won't work without a pile of fixups, and the "bug" it will be due to is
that some code that you now require is temporarily and intentionally missing.
How to develop against linux-next
Well, if you're running a development tree, it isn't eligible for inclusion into linux-next,
since linux-next only consists of everything that will go in in the next merge window. What
you'd be developing this way is a patch series being posted to a mailing list and refined.
Once it's ready for inclusion, and everyone's signed off, then you get your own tree or send
them to a subsystem maintainer (and usually the latter if you have conflicts against linus
because you need to go through the tree of the subsystem you're in conflict with).
With this method of development, you can be targeting 2.6.n+1 since the delta between linus
and linux-next goes to zero within the merge window.
The whole point of developing against linux next is to see where you do pick up conflicts. If
you do and you don't resolve them (which the rebasing method allows you to), Linus is hardly
going to choose to merge your tree over the subsystem tree you just conflicted with. It's far
easier to resolve conflicts incrementally (as in daily) than wait for weeks and see how bad it
becomes (believe me, I've done both).
How to develop against linux-next
What I did was "get init" and then configured the remotes. Upon configuring the -next remote, I got this lovely response from GIT.
[pid 21426] connect(4, {sa_family=AF_INET, sin_port=htons(9418), sin_addr=inet_addr("149.20.4.72")}, 16) = 0
[pid 21426] dup(4) = 5
[pid 21426] write(5, "0055git-upload-pack /pub/scm/lin"..., 85) = 85
[pid 21426] read(4, "", 4) = 0
[pid 21426] write(2, "fatal: The remote end hung up unexpectedly
"..., 43) = 43
How to develop against linux-next
How to develop against linux-next
An example:How to develop against linux-next
mkdir -p ~/src/kernel/
cd ~/src/kernel/
git init linux-next
cd linux-next
git remote add -t master -f linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git remote add -t master -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git checkout remotes/next/master
git branch base
# vi/edit/commit/*rebase/view/ect till your harts content.
* Rebase done using instructions in original article, AFAIK.