Messages in this thread | | | Date | Fri, 12 Jun 2009 01:26:34 +0100 | From | Al Viro <> | Subject | Re: [GIT PULL] Performance Counters for Linux |
| |
On Thu, Jun 11, 2009 at 04:25:19PM -0700, Linus Torvalds wrote: > > > On Fri, 12 Jun 2009, Al Viro wrote: > > > > Linus, the real question that needs to be answered is this: > > No it's not. > > People have already told you that the intent isn't to change the ABI. So > your whole "hard-hitting journalism" is just bogus posturing. > > What does this have to do with anything?
Oh, for... I can bloody well read, I've seen the reply from Peter and I've no reasons to doubt his words (and if I had, I would've said so). Not the issue. I don't know who you are confusing me with, but for the record - I have no problem with this particular code being in tree.
I do have a problem with another thing: suggestions I've heard quite a few times before; basically, "let's allow special breakable ABIs for use by userland code living in kernel tree and tied to specific version". No, I'm not saying that this is what's happening with that merge. But your support for userland code in the tree (and BTW, I agree that it's a good idea - hell, mount(8) makes a good candidate as far as I'm concerned) will be parsed as green light for that. Has been already, in this thread.
So could you please clarify the situation? If the ABI compatibility requirements remain the same as they used to be, whether the userland code is in-tree or not, I'm fine with the entire thing. If they do not (and *ONLY* in that case), I think we have a real problem.
For the record, I don't give a damn about packaging-related arguments and theories about keeping userland source separate as a matter of some principle. As far as I'm concerned, it's not a problem - as long as we take care of later version's $TOOL working on older kernel as well as $TOOL from that older kernel used to work, I'm fine with it.
I realize that multi-side flamefests are messy, but let's keep track of who's saying what, OK?
| |