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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6193.1343211798@warthog.procyon.org.uk>
Date:	Wed, 25 Jul 2012 11:23:18 +0100
From:	David Howells <dhowells@...hat.com>
To:	Michael Kerrisk <mtk.manpages@...il.com>
Cc:	dhowells@...hat.com, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, arnd@...db.de, tglx@...utronix.de,
	mingo@...nel.org, davej@...hat.com
Subject: Re: [PATCH 00/13] UAPI header file split

Michael Kerrisk <mtk.manpages@...il.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/