On Fri, 10 Nov 2000 richardj_moore@uk.ibm.com wrote:
>
>
>
> > The problem with the hooks et.al. is very simple - they promote every
> > bloody implementation detail to exposed API. ....
>
> Surely not, having the kernel source does that. The alternative to the hook
> is embed a patch in the kernel source. What proveds greater exposure to
> internals: hooks of source?
Sorry. You don't "embed" the patch. You either get it accepted or not.
Or you fork the tree and then it's officially None Of My Problems(tm).
If your private patch breaks because of the kernel changes - too fscking
bad, it's still None Of My Problems(tm). With hooks you have a published
API.
Alternative to hook is not a random patch. It's finding a way to use public
APIs (possibly at the cost of redesigning your code) or finding good arguments
for changing said APIs (ditto). And they'ld better be really good. "I don't
know how to do that without rethinking my code" doesn't cut it. Deal. There
is _no_ warranty that anything other than public APIs will not change at any
random moment. Period. You play with layering violations - you _will_ shoot
yourself in foot. It's not "if", it's "when".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Nov 15 2000 - 21:00:16 EST