[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.1.00.0806171852550.19665@iabervon.org>
Date: Tue, 17 Jun 2008 22:40:52 -0400 (EDT)
From: Daniel Barkalow <barkalow@...ervon.org>
To: Greg KH <gregkh@...e.de>
cc: Ingo Molnar <mingo@...e.hu>, David Miller <davem@...emloft.net>,
arjan@...ux.intel.com, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
tglx@...utronix.de, linville@...driver.com, davej@...hat.com
Subject: Re: Oops report for the week preceding June 16th, 2008
On Tue, 17 Jun 2008, Greg KH wrote:
> On Tue, Jun 17, 2008 at 02:43:02PM -0400, Daniel Barkalow wrote:
> >
> > On the other hand, it would be good if there were a way to include
> > unstable APIs in the mainline kernel so that they could get some exposure
> > before they're set in stone, and that would also eliminate that reason for
> > keeping drivers out so long.
>
> That's exactly what the documentation in Documentation/ABI is there for.
> Document your "experimental" API, along with any userspace programs that
> are using it, and work to try to finalize it.
Documentation/ABI/README doesn't list an "experimental" level of
stability. I suppose a developer with an API they expect to change could
create it as "obsolete" (since the experimental verison will get removed
when the real one is done), but that's a little odd as a use of that
category. Also, that doesn't stop people from looking through sysfs for
useful stuff they expect to be undocumented but easy enough to figure out,
and starting to use it without realizing that it's not intended to be
maintained. And the "stable/syscalls" entry implies that all syscalls are
stable when they get merged, which means that a patch that adds a syscall
can't stablize in mainline.
If there are people, like the Nouveau developers, using the instability of
their userspace API as a reason not to submit their drivers, and we would
ideally like the drivers to stabilize with mainline exposure, then we need
to do something more to address these authors' concerns.
-Daniel
*This .sig left intentionally blank*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists