On Wed, Jul 25, 2012 at 12:23 PM, David Howells [off-list ref] wrote:

Michael Kerrisk [off-list ref] wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

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.

quoted

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/