lkml.org 
[lkml]   [2012]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 00/13] UAPI header file split
On Wed, Jul 25, 2012 at 12:23 PM, David Howells <dhowells@redhat.com> wrote:
> Michael Kerrisk <mtk.manpages@gmail.com> wrote:
>
>> A few other points that I noticed now...
>>
>> 1. GIT HISTORY COULD BE RETAINED IN SOME CASES
>> ...
>> But, as currently scripted the "new" uapi header file does not carry
>> over the git history of the old "kapi" header, even though it is an
>> exact duplicate of that file.
>
> How do you retain git history? Git relies entirely on the git client to
> notice the rename or excision within a single commit - and this seems to work.
>
> No history derivation clues are stored in the git repo. It only stores that
> the tree was at point A and is now at point B. How it got there is not
> recorded.
>
>> i.e., those cases would be better scripted as the equivalent of
>> a 'git mv'.
>
> That's just a macro for "mv; git rm; git add", I believe.

Whoops, my bad. I knew all that, but I'd forgotten the use of
"--follow" to allow "git log" to do the right thing. Please ignore
what I said here.


>> 2. EMPTY UAPI HEADERS
>>
>> Some of the resulting uapi header files are empty:
>> ...
>> I imagine this should be reasonably easy to fix.
>
> Fix how? The Kbuild files say these headers must exist in UAPI space, but the
> __KERNEL__ guards therein don't define any content for them in UAPI.

I'm not sure of the answer here. It certainly seems odd to have a
bunch of new empty header files in the kernel tree, which is why I
commented on it. Without digging much deeper, I've no idea whether the
Kbuild files can be (automatically?) modified not to require these
empty files.


>> 3. HEADER COMMENTS NOT RETAINED IN KAPI FILES
>>
>> Another point that may be more difficult to fix is the following. Your
>> scripting is predicated on a header file structure that looks like
>> this:
>>
>> /* Header comments (copyright, author, license, etc) */
>> #ifndef _GUARD_MACRO_H
>> #define _GUARD_MACRO_H
>> ...
>> #endif
>>
>> And the header comments get (sensibly) duplicated in the new uapi header file.
>>
>> But some of the header files have this structure:
>>
>> #ifndef _GUARD_MACRO_H
>> #define _GUARD_MACRO_H
>> /* Header comments (copyright, author, license, etc) */
>> ...
>> #endif
>
> Yeah. The problem was that the header following the guard also might not be
> such, but as you say, checking for:
>
> copyright
> author
> licen[sc]e
> GPL
> warranty
> warranties
> merchantability
> liability
>
> in the comment might well work.
>
>> Some special casing or manual prepatching might best handle the
>> following files, where it looks like there are two comments that
>> should ideally be retained:
>
> I see.
>
>> Some other special casing may be needed for these files
>>
>> include/uapi/linux/virtio_console.h
>> include/uapi/sound/emu10k1.h
>> include/uapi/linux/netfilter/xt_connmark.h
>
> Hmmm. Well, the virtio_console.h comment can actually be suitably modified to
> get rid of the bit about __KERNEL__ for the UAPI file, I think.
>
> It's looking like any comment that mentions one or more of the key words above
> should be duplicated.

I think I forgot to mention that I quickly manually inspected a number
of likely looking files, and the heuristic in my script captured
nearly all of the relevant cases.


>> 4. DISINTEGRATE MARKERS LEFT OVER (?)
>>
>> Some of the DISINTEGRATE markers that you create during the scripting
>> process are left in the final uapi files. Was this intentional?
>
> Ummm... no, there shouldn't be any.
>
> Certainly the marker has worked (the __KERNEL__ guard got retained), but I'm
> not sure why it didn't get removed. Probably my understanding of the black
> magic required to make perl do what I want is lacking.

So, a manual fix may be in order?

Cheers,

Michael


--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/


\
 
 \ /
  Last update: 2012-07-25 13:41    [W:1.859 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site