Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: Kernel interface changes (was Re: cdrecord problems on | Date | 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/
| |