Re: Kernel interface changes (was Re: cdrecord problems on
H. Peter Anvin (hpa@transmeta.com)
Sat, 6 Feb 1999 13:56:37 -0800 (PST)
> > Let me do a translation of what I think everyone is saying here:
> [snip]
> > * Linux will not do such layering for everything. However, there is
> > no reason why one can't build a layered ABI adapter (effectively an
> > ABI to API converter) on top of Linux. This implies some
> > performance cost, but will allow binary modules to work more or less
> > indefinitely, barring huge changes to the kernel internals.
>
> Erm... Or not-so-huge ones. Scenario: semaphore that should be grabbed in
> VFS being grabbed by each fs driver. Race is found. Thing moves to VFS
> (where it belongs) and now we should remove it from each fs in existance
> (deadlocks). I'm afraid that no ABI will save in such situation. Yup, it's
> not a pleasant thing to fix and nobody sane would do it just for fun -
> there is a lot of filesystems in official tree, to start with.
Sure: an ABI where the ABI shim grabbed the semaphore. You *are*
going to have performance degradation with a ABI shim, but you can
probably get away with isolating a large class (but not all!!) of
issues from the main kernel with proper design.
> Another thing: policy wrt exporting stuff. *Any* exported symbol is a
> potential boat anchor.
If you let it be, yes.
-hpa
-
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/