lkml.org 
[lkml]   [2009]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] Performance Counters for Linux
Sam Ravnborg wrote:
> On Thu, Jun 11, 2009 at 09:26:55AM -0700, Linus Torvalds wrote:
>>
>> On Thu, 11 Jun 2009, Christoph Hellwig wrote:
>>> Err, no. This adds tons of userspace code into tools/ which
>>> should not be in the kernel tree but a proper package.
>> I disagree.
>>
>> We've had tons of cases where we tried to "separate" the user-land code
>> and the kernel code, in the name of "beauty" of whatever.
>>
>> It's almost invariably a disaster.
>
> This is cheating. I had this as a topic for the kernel summit and
> was looking forward to read an interesting article about people
> dancing on the table and fighting in the corners about it.
> [I do not attend myself]
>
> People say that this would be a nightmare for the packagers.
> I frankly do not see what the issue is here.

Kernels don't fit well in distribution models.
We have distribution since 15 (and more) years, but still with
hackish support for kernels.

Kernel:
- people are used to install multiple "parallel" kernels
- from different sources (distribution, kernel.org)
- and a lot of people configure own kernel

This is a lot different of usual packages:
- packages have dependencies (done at pre-installation time)
- packages normally support only upgrades (and not downgrades)
- support for multiple version exist only on libraries (SONAME)

Thus a program could depends on specific version of the libc,
but it cannot depends on a specific kernel (system doesn't know
the kernel of next boot), which requires a lot of hack in init.d
scripts.

BTW one of the most frequent question on distribution was
about configuring the kernel and the error about missing
lib[n]curse[X]-dev[el].

So the 15 year without finding a good solution could explains the
nightmare, (but it could be finally the opportunity to really
solve the problem).

To conclude: a user space program should not only have a stable
ABI, but also have nice messages about unsupported features
(and wrong kernel) and not changing runtime dependencies like
socks.

ciao
cate


\
 
 \ /
  Last update: 2009-06-15 15:59    [W:0.162 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site