Messages in this thread | | | Date | Mon, 27 Feb 2006 12:13:23 -0800 | From | Greg KH <> | Subject | Re: [RFC] Add kernel<->userspace ABI stability documentation |
| |
On Mon, Feb 27, 2006 at 03:01:07PM -0500, Benjamin LaHaise wrote: > On Mon, Feb 27, 2006 at 11:46:23AM -0800, Greg KH wrote: > > Then I suggest you work with the ALSA developers to come up with such a > > "stable" api that never changes. They have been working at this for a > > number of years, if it was a "simple" problem, it would have been done > > already... > > That depends on how it's being approached. Writing an ABI takes effort, > while it tends to be easier to simply write new code.
I agree.
> > Anyway, netlink is in the same category, with a backing userspace > > library tie :) > > > > And, I have nothing against shipping userspace libraries with the kernel > > like this, if people think that's the easiest way to do it. But even > > then, the raw interface is still "private" and you need to use the > > library to access it properly. > > That's a lot easier if it gets installed with the kernel version as part of > the path. That might need some hacking in the dynamic linker. Before going > that far, it should really be a question of putting the ABI and necessary > extensions under a microscope to see how much stability in an ABI is > possible. Perhaps we've been too lax in reviewing extensions to the kernel's > ABI, resulting in things getting to the point where it now needs to be a > more explicit part of the review process. > > Half the problem is that the bits that actually form an ABI tend to be > spread over random .c source files, include/asm and include/linux, so > catching a change is rather difficult even for experienced reviewers. It > might make sense to start splitting out the structure definitions into an > include/abi/ structure to make changes easier to spot. It'll be a lot of > work, but along the lines of the whole ioctl mess the end result will be > an easier system for users to cope with (which is the main concern in > maintaining an ABI -- making needless updates necessary for users and > software authors is something I feel we should try to avoid).
Again, I agree. People (including Linus) have said they will accept something like include/abi/ (it was a different name last time that I can't remember), but no one has done the work yet...
thanks,
greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |