Am Samstag, 9. Dezember 2006 11:39 schrieb Thomas Graf:
[Added linux-kernel to CC]
> Index: net-2.6/Documentation/feature-removal-schedule.txt
> ===================================================================
> --- net-2.6.orig/Documentation/feature-removal-schedule.txt 2006-12-09
NAK.
> +What: Netlink message and attribute parsing macros
> +When: July 2007
> +Why: The old interface which often lead to buggy code has been replaced
> + with a new type safe interface. Parts of this interface, mainly
> + macros, has been exported to userspace via linux/netlink.h and
> + linux/rtnetlink.h. Use of this interface is discontinued, all
> helper + and utility macros will be removed. Userspace applications
> should use + one of the available libraries.
> +Who: Thomas Graf <[email protected]>
So glibc should be linked to libnl that depends on glibc to compile? Be
serious!
I see a worrying tendency of kernel developers trying to push their
stable-api-is-nonsense approach to userspace. You cannot just go ahead and
remove userspace API that has been exported for years in a six month period.
99,9% of application developers are not even aware that
feature-removal-schedule.txt exists. Sorry, these macros will have to stay
for *years*, even though they are ugly.
Btw, do you know why I didn't realize the breakage before a user alerted me? I
stopped testing and running every new kernel. Reason? It was stated that
2.6.18 requires a mandatory upgrade of udev bloat. Last time I needed to
compile a new udev because of incompatible sysfs changes, it took me over
three hours to get my notebook running again. Considering that I need to do
actual money earning work on that system, 2.6.17.x runs nicely and has no new
bugs that concern me, I just keep using it. Collateral damage.
You know, I'm not so happy with the in kernel stable-api-is-nonsense approach
because it does create insecurity for developers and therefore bugs. Anyway,
I accept it, I'm just a part time kernel hacker. But behaving towards
applications developers this way is *deadly* for linux acceptance! Stuff like
KDE, or a postgres database server, or whatever is complex enough that
developers don't have time to follow userspace breakage introduced just
because of ugly macros.
Stefan
* Stefan Rompf <[email protected]> 2006-12-09 12:49
> Am Samstag, 9. Dezember 2006 11:39 schrieb Thomas Graf:
>
> [Added linux-kernel to CC]
>
> > Index: net-2.6/Documentation/feature-removal-schedule.txt
> > ===================================================================
> > --- net-2.6.orig/Documentation/feature-removal-schedule.txt 2006-12-09
>
> NAK.
>
> > +What: Netlink message and attribute parsing macros
> > +When: July 2007
> > +Why: The old interface which often lead to buggy code has been replaced
> > + with a new type safe interface. Parts of this interface, mainly
> > + macros, has been exported to userspace via linux/netlink.h and
> > + linux/rtnetlink.h. Use of this interface is discontinued, all
> > helper + and utility macros will be removed. Userspace applications
> > should use + one of the available libraries.
> > +Who: Thomas Graf <[email protected]>
>
> So glibc should be linked to libnl that depends on glibc to compile? Be
> serious!
Please calm down a bit. I didn't claim that glibc should be linking to
libnl. glibc is obviously a special case which can simply copy the existing
macros into some internal compat header just like any other application
that doesn't wish to use any of the libraries available.
The point is to stop new applications from using the interface which has
resulted in buggy code in the past.
Am Samstag, 9. Dezember 2006 13:55 schrieb Thomas Graf:
> Please calm down a bit. I didn't claim that glibc should be linking to
> libnl. glibc is obviously a special case which can simply copy the existing
> macros into some internal compat header just like any other application
> that doesn't wish to use any of the libraries available.
But when even glibc needs internal compat headers to compile with the second
kernel version that provides userspace headers, what is the long-term - even
mid-term - perspective of make headers_install then?
Stefan
From: Thomas Graf <[email protected]>
Date: Sat, 9 Dec 2006 13:55:33 +0100
> The point is to stop new applications from using the interface which has
> resulted in buggy code in the past.
You don't get people to use new interface by breaking the
build on them in userspace.
You get them to do it by making suggestions and informing them, not
by forcing them.
That's why 1) you can't get rid of these macros, ever, but 2) you can
warn them by using inline functions and depcrecated attribute tags.
From: Stefan Rompf <[email protected]>
Date: Sat, 9 Dec 2006 15:58:01 +0100 (MET)
> But when even glibc needs internal compat headers to compile with the second
> kernel version that provides userspace headers, what is the long-term - even
> mid-term - perspective of make headers_install then?
Relax Stefan, I'll make sure these macros never go away.
They may emit warnings, via __attribute__((deprecated)), at
some point, but they will never be flat out removed.
On Sat, 2006-12-09 at 15:58 +0100, Stefan Rompf wrote:
> But when even glibc needs internal compat headers to compile with the second
> kernel version that provides userspace headers, what is the long-term - even
> mid-term - perspective of make headers_install then?
We've only _just_ started paying attention to what we export. I tried to
keep the initial cut of headers_install very simple and uncontentious --
sticking to implementation, and not policy. So I didn't do a
particularly thorough cull of stuff that we shouldn't be exposing --
it's expected that we may lose _some_ more stuff.
But breaking userspace like _this_ isn't acceptable, and we're not doing
it.
--
dwmw2
On Sat, 2006-12-09 at 15:58 +0100, Stefan Rompf wrote:
> But when even glibc needs internal compat headers to compile with the second
> kernel version that provides userspace headers, what is the long-term - even
> mid-term - perspective of make headers_install then?
Bear in mind that with the first cut of the headers_install I was trying
to keep it entirely uncontentious and stick to _mechanism_, not policy.
The _first_ set of exported headers still aren't ideal, and we're still
cleaning up some parts of them (like properly getting rid of the
_syscallX() macros, etc.).
We've only just started to be sensible about what we export to userspace
-- it's not entirely set in stone at this point,
--
dwmw2