how is that any different then a module? modules that are not included
with the kernel source are not guarenteed to work with any other kernel
version (including during the stable kernel series)
David Lang
On Fri, 10 Nov 2000, Alexander Viro wrote:
> On Fri, 10 Nov 2000 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
