[lkml]   [2006]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] 'make headers_install' kbuild target.
    On Sat, 2006-04-22 at 11:33 +0200, Adrian Bunk wrote:
    > My thirst thought is:
    > Is this really the best approach, or could this be done better?

    I think it's the best way to start, although I agree with you entirely
    about what we should strive for in the end.

    > I'm currently more a fan of a separate kabi/ subdir with headers used by
    > both headers under linux/ and userspace.

    I agree -- I'd like to see that too. But Linus doesn't like that
    approach very much.

    > Unless I'm misunderstanding this, your changes are giving a result
    > identical result to simply using the current kernel headers (stripping
    > the #ifdef __KERNEL__ stuff doesn't change anything).

    It's not quite the same. Some headers which just shouldn't be there at
    all are removed -- and others can no longer be abused by defining
    __KERNEL__ to get at stuff which shouldn't be there.

    Also, if we have an 'exported' set of files which is supposed to be
    clean, we can easily _see_ when there's stuff which shouldn't be there.
    It makes the cleanup easier, by making the mess more obvious. We can
    also take diffs of the output between one kernel and the next, applying
    electric shocks as necessary, as you suggest later.

    It's a small step, but it's the _first_ step towards the point we want
    to reach, and it's something we're likely to get away with.

    Ideally, I'd like to proceed by splitting files into user-visible and
    kernel-private parts in _separate_ headers, so that the 'unifdef' part
    becomes unnecessary (and __KERNEL__ disappears entirely). I've done some
    of that already in include/mtd). It would also be nice if we could then
    put the user-visible files into a separate directory, so that the
    'headers_export' step becomes nothing more than a 'cp -a'. We do need to
    do this incrementally though, and I think this is going to be the best
    way to do it, and to get it accepted.

    > Unless someone can tell me a reason why this wouldn't work (except for
    > being a bit more work than your approach), this is the approach I have
    > in mind for working on.

    Your approach is basically what we proposed at last year's Kernel
    Summit. It was shot down though, so we're trying to start simple and do
    it incrementally.

    The important thing is that we all get our editors out and clean up the
    _contents_ our own headers, and actually start to _think_ about the
    visibility of any new header-file content we introduce. Let's not
    concentrate too much on the implementation details of how we actually
    get those to userspace.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-22 22:16    [W:0.031 / U:2.240 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site