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]

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

On Wed, Jul 25, 2012 at 12:23 PM, David Howells <dhowells@...hat.com> wrote:
> 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.

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