lkml.org 
[lkml]   [2012]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 00/13] UAPI header file split
Date
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.

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

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

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

David


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