Stefan Rompf <[EMAIL PROTECTED]> wrote:
>
> Yes, the code has quite some trust into the kernel that if it answers the
> asked question the answer is semantically correct. But to be fair, if you
> issue a write(), you also expect the number of bytes written in return and
> not the msec taken ;-)
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 f
Am Sonntag, 10. Dezember 2006 13:15 schrieb Thomas Graf:
> > Please send me the list of bugs you've spotted. Of course I want to fix
> > them.
>
> Sure...
>
> static void nl_handlemsg(struct nlmsghdr *msg, unsigned int len) {
> if (len < sizeof(*msg)) return;
>
> while(NLMSG_OK(msg,len)) {
>
On Sat, Dec 09, 2006 at 08:42:45PM -0500, Jeff Bailey wrote:
> On 09/12/06, David Miller <[EMAIL PROTECTED]> wrote:
> >You can't deprecate stuff visible to userspace, sorry Thomas,
> >we just can't do it.
> >
> >You can migrate people to "better" interfaces, but you can't
> >pull the rug out from a
On 09/12/06, David Miller <[EMAIL PROTECTED]> wrote:
You can't deprecate stuff visible to userspace, sorry Thomas,
we just can't do it.
You can migrate people to "better" interfaces, but you can't
pull the rug out from anyone once things like this are visible
to userspace. It's permanently ther
* David Miller <[EMAIL PROTECTED]> 2006-12-09 13:45
> You can't deprecate stuff visible to userspace, sorry Thomas,
> we just can't do it.
It has been done before but I don't want to drag this on
any further. I did what I found to be right and obviously
I've hit a wall.
> Once idea I have is that
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 pa
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?
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
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Sat, 9 Dec 2006 11:39:53 +0100
> +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 interfa
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 wi
* 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
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.
>
Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Index: net-2.6/Documentation/feature-removal-schedule.txt
===
--- net-2.6.orig/Documentation/feature-removal-schedule.txt 2006-12-09
11:29:25.0 +0100
+++ net-2.6/Documentati
14 matches
Mail list logo
