Hello.
In article <[EMAIL PROTECTED]> (at Mon, 18 Sep 2006 20:57:46 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
> * YOSHIFUJI Hideaki <[EMAIL PROTECTED]> 2006-09-19 00:08
:
> > [NET]: Include new rtnetlink headers for userspace backward
> > compatibility.
:
> > diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> > index 3a18add..8ec375c 100644
> > --- a/include/linux/rtnetlink.h
> > +++ b/include/linux/rtnetlink.h
> > @@ -2,7 +2,12 @@ #ifndef __LINUX_RTNETLINK_H
> > #define __LINUX_RTNETLINK_H
> >
> > #include <linux/netlink.h>
> > +#ifndef __KERNEL__
> > +/* Backward compatibility */
> > #include <linux/if_link.h>
> > +#include <linux/if_addr.h>
> > +#include <linux/neighbour.h>
> > +#endif
> >
> > /****
> > * Routing/neighbour discovery messages.
>
> Still acceptable but this gets ugly at some point. Applications using
> the interface should start making copies of the header version they
> use.
I understand, but I feel it is more ugly.
> > commit 55a08a9078b243a06223222735580df9e11a5fa6
> > Author: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> > Date: Sun Sep 17 13:55:02 2006 +0900
> >
> > [NET]: Put {IFLA,IFA,NDA,NDTA}_{RTA,PAYLOAD}() macro back.
> >
> > These macros are still used by userspace applications.
>
> Same here, it doesn't make sense to export macros only of functional
> value and used by userspace only. The same issue will pop up once
> all users have been converted to use the new netlink interface.
> Keeping the old interface around just so userspace doesn't have to
> make copies doesn't make sense. I think it's better to start fixing
> userspace than to try and keep headers source compatible.
Backward compatibility is one of the most important factor.
A careless breakage is, say, of "brain freeze."
About these macros, we have other similar *_{RTA,PAYLOAD}()s in kernel,
which are not used by kernel but are exported to userspace. They are
forming part of our API, and they're good example how to use netlink
interface.
Yes, we could change the interface, but we definately need to give
them graceful period at least; we can do it in 2.7, or at least,
after 2-3 stable releases.
Regards,
--
YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
