linux-kernel - Re: [arc-linux-dev] Re: UAPI for new arches (was Re: [GIT PULL] User API Disintegrate: Preparatory patches)

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: <50A0D634.20005@synopsys.com>
Date:	Mon, 12 Nov 2012 16:27:56 +0530
From:	Vineet Gupta <Vineet.Gupta1@...opsys.com>
To:	<arc-linux-dev@...opsys.com>
CC:	David Howells <dhowells@...hat.com>,
	James Hogan <james@...anarts.com>,
	"torvalds@...l.org" <torvalds@...l.org>,
	"arnd@...db.de" <arnd@...db.de>, "hpa@...or.com" <hpa@...or.com>,
	"alan@...rguk.ukuu.org.uk" <alan@...rguk.ukuu.org.uk>,
	"fengguang.wu@...el.com" <fengguang.wu@...el.com>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [arc-linux-dev] Re: UAPI for new arches (was Re: [GIT PULL] User
 API Disintegrate: Preparatory patches)

On Friday 09 November 2012 04:49 AM, David Howells wrote:
> Vineet Gupta <Vineet.Gupta1@...opsys.com> wrote:
>
>> While I'd done some of the prep work in my code such as splitting __KERNEL__
>> && __ASSEMBLY__ into two separate lines, majority of orig headers didn't
>> have #ifdef __KERNEL__ guard despite the code not being meant for user-space
>> ABI. Is that fundamental to UAPI split scripting
> Yes.  My scripts work purely along __KERNEL__ lines.  If there are no
> __KERNEL__ markers and the header is marked for export, it is simply moved.

Understood.

>
>> because it seems to be causing setup.h to be in uapi despite seemingly being
>> kernel internal only.
> Check also include/uapi/asm-generic/Kbuild.asm.  That exports setup.h, whether
> you think it should be exported or not.

Correct. And if there's nothing to export in there the script will not
generate the empty uapi sibling.

>> Per you email from last week, When I ran the disintergrate-one.pl script
>> myself I saw a whole bunch of empty UAPI files being generated with
>> references in orig header.  I'm not sure what I'm doing wrong.
> Can you give an example of such a header?

tlb.h - despite having __KERNEL__ guard in orig file. Here's how I did it.

1. In my orig tree, I created arch/arc/include/uapi/asm/Kbuild, with
following 2 lines

# UAPI Header export list
include include/uapi/asm-generic/Kbuild.asm

2.  ./disintegrate-one.pl arch/arc/include/asm/tlb.h
arch/arc/include/uapi/asm/tlb.h

This generates a empty uapi/asm/tlb.h, a reference to it in asm/tlb.h
and is also exported from Kbuild.asm - all 3 of which are wrong.

But now that I think about it - I was wrong to call this script for
all/any arch headers. It should be done only for the ones in
include/uapi/asm-generic/Kbuild.asm or any specific ones that arch wants
to export (cachectl.h for our case).

>
>> For any ABI changes to headers per review of the new port on list
>> (e.g. don't export pt_regs) would mean moving the code manually from uapi to
>> orig header - right. And if the file becomes empty just nuke it completely.
> You can't necessarily remove a UAPI header completely.  Userspace may depend
> on its existence, even if it gets no content from there.
>
>> How do you reckon we go about fixing these. I don't want to bother you
>> multiple times hence it would be best if I could reproduce this at my end.
> The best advice I can give you without more specific examples is to compare
> what's in your arch's headers to those of, say, hexagon or arm64.  Those are
> recent additions and should be pretty clean as to what they contain.
>
> 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/