Linus Torvalds [off-list ref] writes:
On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
[off-list ref] wrote:
quoted
In a hopeless quest to avoid conflicts when merging a new system call
and wiring it up I have pulled in bits of net-next and the parisc tree.
You have already pulled the net-next bits. The parisc bits in my tree
are:
Ok, this just means that I won't pull from you.
Sure. I will try to be a little more patient and resend the pull
request after James has sent the pull request for the parisc tree.
At which point the only unique changes in my tree will be mine.
It's that simple. We don't do this. Ever.
Hah. I seem to remember bits of pulling from non-rebasing trees being ok
in well defined contexts. This seems like one. Especially when you
have checked with the maintainers.
Plus all of the parisc bits in addition to being in the linux-next
are trivially correct.
Why the hell did you even worry about wiring up parisc system calls?
That's not your job.
Because in general it is the job of he who changes something to fix up
every possible place.
Now maybe I went a little too far in trying to resolve the conflicts,
but I did check with the David Miller and James Bottomley and they knew
what I was doing.
Quite honestly adding system calls is a mess that know one seems to
know how to do right. So I flipped a coin and took a stab at it.
Eric
On Sat, 2011-05-21 at 17:33 -0700, Eric W. Biederman wrote:
Linus Torvalds [off-list ref] writes:
quoted
On Sat, May 21, 2011 at 4:39 PM, Eric W. Biederman
[off-list ref] wrote:
quoted
In a hopeless quest to avoid conflicts when merging a new system call
and wiring it up I have pulled in bits of net-next and the parisc tree.
You have already pulled the net-next bits. The parisc bits in my tree
are:
Ok, this just means that I won't pull from you.
Sure. I will try to be a little more patient and resend the pull
request after James has sent the pull request for the parisc tree.
At which point the only unique changes in my tree will be mine.
Right ... effectively you're running a postmerge tree, since you now
depend on bits I have in the parisc tree.
Traditionally, the arch trees tend to go a bit later because they wait
to see if there's any fallout from x86; but this time, I think it looks
OK, so I've sent the pull request:
http://marc.info/?l=linux-parisc&m=130604805417277
As soon as that's in, you should be good to go.
James
quoted
It's that simple. We don't do this. Ever.
Hah. I seem to remember bits of pulling from non-rebasing trees being ok
in well defined contexts. This seems like one. Especially when you
have checked with the maintainers.
Plus all of the parisc bits in addition to being in the linux-next
are trivially correct.
quoted
Why the hell did you even worry about wiring up parisc system calls?
That's not your job.
Because in general it is the job of he who changes something to fix up
every possible place.
Now maybe I went a little too far in trying to resolve the conflicts,
but I did check with the David Miller and James Bottomley and they knew
what I was doing.
Quite honestly adding system calls is a mess that know one seems to
know how to do right. So I flipped a coin and took a stab at it.
Right, the solution is reasonable and means linux-next doesn't have to
carry a conflict resolution patch for this. It also means we agree on
the syscall numbering ...
The only real mistake was not waiting for the merge sequence: the base
trees have to go first before you can push a postmerge tree.
James
* James Bottomley [off-list ref] wrote:
Traditionally, the arch trees tend to go a bit later because they wait to see
if there's any fallout from x86; [...]
Not really - most of the arch trees 'traditionally' went late even when the x86
tree itself was monolithic and was itself sent late in the merge window (with
the notable exception of the powerpc tree).
[...] but this time, I think it looks OK, [...]
That's not really a surprise, there hasn't been a serious 'problem' with the
x86 tree for a long time, roughly since we switched to the finegrained Git
topical split-up maintenance model about two years ago.
[ That split-up also means that there is no 'x86 tree' anymore as such: if you
check lkml we send roughly 20-30 independent trees in the merge window and
have done that for the past ~10 kernel cycles. ]
In fact exactly *because* there's few problems with the x86 topic trees can we
push them so soon: if problems were frequent then 1) we would not be able to be
ready on time and 2) i suspect we'd be pulled in later in the window as well as
a maintainer generally wants to pull low risk items first, high risk items
last, to maximize the utilization of testing capacity.
I agree with Linus's notion in this thread though, a core kernel change should
generally not worry about hooking up rare-arch system calls (concentrate on the
architectures that get tested most) - those are better enabled gradually
anyway.
Also, system call table conflicts are trivial to resolve. Merging in net-next
to avoid such a conflict is like cracking a nut with a sledgehammer.
Thanks,
Ingo