Re: [arc-linux-dev] Re: UAPI for new arches (was Re: [GIT PULL] User API Disintegrate: Preparatory patches)
James Hogan wrote: > The disintegration scripts strip out the #ifdef __KERNEL__ from the > headers in both uapi/ and the old directories. However there are still a > bunch of unexported headers through the tree which have #ifdef > __KERNEL__ in them, usually guarding the entire file (just grep > __KERNEL__ in arch/). > > Is this something that you're already planning to eliminate? We have a > few in the metag tree too, and now that uapi/ is nicely separated I'm > not sure if it's worth removing the __KERNEL__ guards or keeping them to > match other architectures. I would like to remove the __KERNEL__ guards from KAPI files - they should not be necessary there. In the UAPI files, it will, unfortunately, be necessary to keep some of the __KERNEL__ guards that remain. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [arc-linux-dev] Re: UAPI for new arches (was Re: [GIT PULL] User API Disintegrate: Preparatory patches)
Hi David, The disintegration scripts strip out the #ifdef __KERNEL__ from the headers in both uapi/ and the old directories. However there are still a bunch of unexported headers through the tree which have #ifdef __KERNEL__ in them, usually guarding the entire file (just grep __KERNEL__ in arch/). Is this something that you're already planning to eliminate? We have a few in the metag tree too, and now that uapi/ is nicely separated I'm not sure if it's worth removing the __KERNEL__ guards or keeping them to match other architectures. Thanks James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [arc-linux-dev] Re: UAPI for new arches (was Re: [GIT PULL] User API Disintegrate: Preparatory patches)
Vineet Gupta wrote:
> >> 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.
Actually, this is the correct operation - it's just that there's nothing in
tlb.h to export. (Note that Kbuild.asm is not modified, but rather
uapi/asm/Kbuild. asm/Kbuild would too, but there's no export line there to be
removed.)
However... tlb.h isn't exported in Kbuild.asm - nor is it exported in arc's
asm/Kbuild, so the script shouldn't be run on that.
> 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).
Exactly so. I should probably have mentioned that, but I've had it automated
for so long, that I don't think about it any more. You should only call it
for arch headers
I've attached a script that I use to work out which files need disintegration
in a directory. Run as:
genfilelist.pl arch/arc/include/asm/
I get:
byteorder.h
cachectl.h
page.h
ptrace.h
setup.h
sigcontext.h
signal.h
swab.h
unistd.h
as being all that you need to disintegrate. Almost everything seems to be
generic.
David
#!/usr/bin/perl -w
#
# Find all the UAPI files in the nominated directory
#
die "Need directory argument\n"
if ($#ARGV == -1);
my $dir = $ARGV[0];
my $kbuild = $dir . "/Kbuild";
die "$kbuild not present"
unless (-r "$dir/Kbuild");
#
# We assume that only Kbuild files in include directories are pertinent to
# determining which headers are UAPI headers.
#
my %headers = ();
opendir my $dh, $dir or die;
foreach $_ (readdir($dh)) {
$headers{$_} = 1
if ($_ =~ /[.]h$/ || $_ =~ /[.]agh$/ || $_ =~ /[.]inc$/);
}
closedir($dh) or die;
# Read the common arch list
open FD, ';
close FD or die;
my %uapihdrs = ();
open FD, '<', $kbuild or die "open $kbuild: $!\n";
my @lines = ;
close FD or die;
for (my $l = 0; $l <= $#lines; $l++) {
my $line = $lines[$l];
# parse out the blocks
# - this may be split over multiple lines using backslashes
my $block = $line;
restart:
$block =~ s@#.*$@@;
$block =~ s@\s+$@@g;
$block =~ s@\s+@ @g;
if ($block =~ /^(.*)[\\]$/) {
$l++;
$block = $1 . $lines[$l];
goto restart;
}
$block =~ s@\s+$@@g;
$block =~ s@\s\s+@ @g;
if ($block =~ m@^include include/asm-generic/Kbuild.asm@) {
push @lines, @kbuild_asm;
}
if ($block =~ m@^header-y\s*[+:]?=\s*(.*)@ ||
$block =~ m@^opt-header\s*[+:]?=\s*(.*)@ ||
$block =~ m@^asm-headers\s*[+:]?=\s*(.*)@
) {
my $files = $1;
next if ($block =~ m@[$][(]foreach@);
foreach $h (grep m@[^/]$@, split /\s+/, $files) {
if (exists $headers{"$h"}) {
$uapihdrs{"$h"} = 1;
}
}
}
}
print map { $_ . "\n"; } sort keys %uapihdrs;
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 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
