Re: [NETLINK]: Schedule removal of old macros exported to userspace

Re: [NETLINK]: Schedule removal of old macros exported to userspace

[Stefan Rompf]

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 <tgraf@suug.ch>

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

Re: [NETLINK]: Schedule removal of old macros exported to userspace

[Thomas Graf]

* Stefan Rompf <stefan@loplof.de> 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 <tgraf@suug.ch>
> 
> 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.

Re: [NETLINK]: Schedule removal of old macros exported to userspace

[Stefan Rompf]

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

Re: [NETLINK]: Schedule removal of old macros exported to userspace

[David Miller]

From: Stefan Rompf <stefan@loplof.de>
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.

Re: [NETLINK]: Schedule removal of old macros exported to userspace

[David Woodhouse]

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

Re: [NETLINK]: Schedule removal of old macros exported to userspace

[David Woodhouse]

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

Re: [NETLINK]: Schedule removal of old macros exported to userspace

[David Miller]

From: Thomas Graf <tgraf@suug.ch>
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.