Messages in this thread | | | Subject | Re: [PATCH] 'make headers_install' kbuild target. | From | David Woodhouse <> | Date | Sat, 22 Apr 2006 13:03:03 +0100 |
| |
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.
-- 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/
| |