No it isn't. I've kept pretty much the same set of drivers in my
standard kernel since 1.2.13 days, and the kernel size went from
about 400k (1.2.13) to 500k (2.0.28+logo) to 600k (2.2.10) to
640k (2.3.6) Some of this is additional driver (VIA IDE support,
but those drivers came into existance at the same time AMD Lance
support was modularised, so it's a wash)
>With a completely open development cycle, and massive amounts of
>communication directly to the developers available (such as with
>linux-kernel), any changes made to internal kernel interfaces (which are
>seldom unnecessary) are open to discussion to any interested party.
Linux isn't a democracy. I can discuss until my face turns red,
but if backwards compatability isn't important to any kernel
developer (I am not a kernel developer; I just hack the kernel
so that it works with my projects) it won't make any difference.
As a general rule, it's a Good Thing that the people who write the
code get to make the rules, but it's also NOT a Good Thing to assume
that everyone is a hobbyist who is willing to patch their codebase
every time a kernel interface is tweaked.
And speaking of patches, this patch to 2.2.10 puts back the
old-style fcntl locking:
[cut here]
--- linux-2.2.10-orig/fs/locks.c Tue May 11 08:52:14 1999
+++ linux-2.2.10/fs/locks.c Wed Jun 23 11:47:11 1999
@@ -441,10 +441,10 @@
current->pid, current->comm);
}
}
+#endif
if (!(filp->f_mode & 3))
goto out_putf;
break;
-#endif
default:
error = -EINVAL;
goto out_putf;
[cut here]
____
david parsons \bi/ This patch also works with 2.3.6.
\/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/