lkml.org 
[lkml]   [2001]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [LONG RANT] Re: Linux stifles innovation...
    On Mon, 19 Feb 2001, Mikulas Patocka wrote:

    > > > I suspect part of the problem with commercial driver support on Linux is that
    > > > the Linux driver API (such as it is) is relatively poorly documented
    > >
    > > In-kernel documentation, agreed.
    > >
    > > _Linux Device Drivers_ is a good reference for 2.2 and below.
    >
    > And do implementators of generic kernel functions and developers of device
    > drivers respect it? And how can they respect it if it's a commercial book?

    _Linux Device Drivers_ documents the 2.2 (and previous) API, and
    thus refutes the argument that the kernel API is poorly documented.
    Since the publication of the book -succeeds- the publication of the
    APIs, your questions are not applicable.


    > > > and seems
    > > > to change almost on a week-by-week basis anyway. I've done my share of chasing
    > > > the current kernel revision with drivers that aren't part of the kernel tree:
    > > > by the time you update the driver to work with the current kernel revision,
    > > > there's a new one out, and the driver doesn't compile with it.
    > >
    > > This is entirely in your imagination. Driver APIs are stable across the
    > > stable series of kernels: 2.0.0 through 2.0.38, 2.2.0 through 2.2.18,
    > > 2.4.0 through whatever.
    >
    > No true. Do you remember for example the mark_buffer_dirty change in some
    > 2.2.x that triggered ext2 directory corruption? (mark_buffer_dirty was
    > changed so that it could block).
    >
    > Another example of bug that comes from the lack of specification is
    > calling of get_free_pages by non-running processes that caused lockups on
    > all kernels < 2.2.15. And it is still not cleaned up - see tcp_recvmsg().
    >
    > Having documentation could prevent this kind of bugs.

    Hardly. No documentation is often -better- than bad documentation.

    > You don't need too
    > long texts, just a brief description: "this function may be called from
    > process/bh/interrupt context, it may/may not block, it may/may not be
    > called in TASK_[UN]INTERURPTIBLE state, it may take these locks."
    >
    > With documentation developers would be able to change implementation of
    > kernel functions without the need to recheck all drivers that use them.

    Anytime you change implementation, you gotta check all drivers that use
    them. I know, I'm one of the grunts that does such reviews and changes.

    > Saying "code is the specification" is not good.

    I'm not arguing against documentation. That is dumb. But the code is
    ALWAYS canonical. Not docs.

    Jeff





    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:15    [W:4.154 / U:1.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site