Re: 2.6.18 Headers - Long
From: Albert Cahalan
Date: Sun Jul 16 2006 - 02:16:44 EST
On 7/15/06, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote:
On Sat, 2006-07-15 at 17:09 -0400, Albert Cahalan wrote:
> Don't blame app developers if they go for what is good.
> To stop them, provide the goodness in a sane way.
> (alternately, make the Linux code suck ass more than POSIX)
Kernel headers are _not_ a library of random crap for userspace to use.
Says you, and a number of other people around here.
App developers seem to feel differently. Accept reality.
There is no justification for asm/atomic.h being installed
in /usr/include. Especially since, as Arjan points out, it doesn't
actually provide atomic operations in many cases anyway.
It's fixable via #ifdef __KERNEL__ of course.
However, the kernel is released under a licence which allows you to
re-use code from it if you really want.
Well, ideally it'd be LGPL, but yes.
If you want to provide a
'libkernelstuff', the GPL permits you to do that. The kernel's ABI
headers (and lkml) are not the appropriate place for such a project
Perhaps. This is duplication of effort though.
You're the person trying to change the app developers.
If you want to change them, provide an alternative that
doesn't totally suck ass.
Btw, your mail client omitted the References: and In-Reply-To: headers
which RFC2822 says it SHOULD have included. On a list with as much
traffic as linux-kernel, that's _very_ suboptimal, because you've
detached your message from the thread to which you replied. Please try
to fix or work around that.
Most clients won't allow adding such headers manually.
I don't actually subscribe to the list. Most clients won't
expire old list traffic, and I certainly can't have lkml pour
unhindered into my inbox. It really doesn't work for me,
so I cut and paste from a list archive. Sorry. Ideas are
welcome of course, but I'm not expecting any reasonable
solution to exist.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/