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 ;-) Will
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
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)) {
if
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
+++
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.
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
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 interface,
* 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 you
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
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?
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
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 there,
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 anyone once
13 matches
Mail list logo
