Re: [PATCH 00/13] UAPI header file split

[David Howells <dhowells@redhat.com>]

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