lkml.org 
[lkml]   [2006]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] 'make headers_install' kbuild target.
    From
    Date
    On Sat, 2006-04-22 at 15:20 +0200, Adrian Bunk wrote:
    > On Sat, Apr 22, 2006 at 01:48:43PM +0100, David Woodhouse wrote:
    > > On Sat, 2006-04-22 at 14:38 +0200, Adrian Bunk wrote:
    > > > What was the recommended way for getting userspace header at last
    > > > year's kernel summit?
    > >
    > > It was said that we need _incremental_ changes, and this is an attempt
    > > to satisfy that request.

    Let me expand on that...

    There are a number of steps which we need to take.

    1. Identify those files which contain stuff which should be
    user-visible. I've done a first pass of this for arch-independent files
    and asm-powerpc already. We need it done for other architectures.

    2. Examine the contents of those files, and separate private parts from
    parts which should be user-visible. This can be by splitting them into
    separate files, or by using ifdefs -- it doesn't matter conceptually at
    _this_ stage as long as the important work of _reading_ the code and
    identifying it as either public or private is done. All else can be
    scripted after that.

    This much is undisputed -- _everyone_ agrees that it's necessary. We can
    do that, and we can have a fairly simple post-processing stage which
    creates a set of 'sanitised' kernel headers which we can inspect, and
    which we can compare between releases. This is _also_ the bulk of the
    real work. It's where we actually have to look at the code and _think_
    about it.

    But it's not _all_ we want to do, ideally. Ideally we want to take it
    further...

    3. Eliminate all the #ifdef __KERNEL__. Ifdefs are horrid -- we all know
    that. We should split public bits into entirely separate files. Once
    it's marked with #ifdef __KERNEL__ after stage #2, it's fairly simple to
    split the files up -- it's scriptable; doesn't really need much thought.

    4. Clean up the directory structure. It really ought to be just a copy
    of certain directories, rather than picking selected files from
    include/linux et al. Again, once we _have_ the public files marked in
    some way, it's trivial to move them around once we agree where they
    should go.

    Linus has said he doesn't want to jump straight in at #4 and start
    moving things around en masse. Adrian, you seem to be saying you won't
    help _unless_ you can send patches which mix #2 and #4 instead of doing
    it incrementally.

    Now, I'm perfectly happy with patches which do that, if you can actually
    get them merged. The export step can happily pick up the headers you've
    moved to include/kabi/ and put them back where userspace expects to see
    them for now.

    In fact, I think it's best to hold off on #4 for now -- not only because
    Linus won't take the patches, but because once we've done steps 1-3
    above, we'll have a _much_ clearer idea of what we have left and how it
    should best be laid out. Maybe once we've moved the crap out of the way
    we'll end up wanting chrdev/*.h, ioctl/*.h, sockopt/*.h etc....

    But even though I think it's premature, I still don't _mind_ moving
    stuff into kabi/ -- because as I said it's _trivial_ to move stuff
    around after it's been cleaned up. That part isn't the interesting part
    of the problem, and I'm uninterested in arguing about it.

    --
    dwmw2

    -
    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: 2006-04-22 20:56    [W:3.206 / U:0.736 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site