| |||||||||||||
User-space ABI / Insulating the userUser-space ABI / Insulating the userPosted May 17, 2007 16:18 UTC (Thu) by filker0 (guest, #31278)Parent article: 2.6 and the user-space ABI
Long before Linux was born, I worked on a small embedded event-driven multi-tasking kernel for an advanced development project on a multi-processor M68k platform. Churn in the ABI became a problem as the hardware and kernel maturatured as the other subsystem teams would move from one subproject to another.
We addressed this problem by adding a thin layer of sand and drawing a line in it. All code written to use an ABI that was written to a newer "stable" base-level would make a system call (we used traps) that identified the version of the ABI it expected. All of the old tasks that did not use a newer ABI would not make the call, and would be assumed to be of the oldest ABI tracked. If the ABI associated with a task was older than the current ABI, an emulation layer that logged the obsolete usage, but still serviced the task by emulating the ABI in question (we used a jump table for this, and had one for each "supported" ABI built in to the kernel). For development, this worked pretty well. Once all of the required functionality was implemented, we used the logs to locate all of the places where the old ABI was used and fix them, then we turned this feature off for the later testing and production builds. We actually left the select ABI system call in place (a no-op for production builds) in each of the tasks so that this could be used in future upgrade cycles.
This cannot be applied to Linux user-space as easily as it was to a small-ish project with under 15 engineers working on it, and I see no way for sysfs changes to be shielded this way (though changes in data structures within sysfs might, with a *lot* of work, be automatically translated in some cases). If a new system call was added to the ABI that registered some base-level compatibility (could be subdivided down to the specific feature or driver level), a table in the TCB could be used to determine how to handle the call. A set of hooks to log deprecated ABI usage could be added so that developers could isolate the ABI changes and get the maintainers of packages that depend on the older ABI to fix them.
I'm not suggesting that this should be done, just that there is a way to design for forward migration in the ABI. There are performance issues with this approach, and it may be harder to do with the context switch mechanism in Linux than it was with the trap instruction based context switch that we were using.
(Log in to post comments)
|
|||||||||||||