Cesar Eduardo Barros wrote:
> Several headers were moved or split to uapi/.
I was going to wait to do this till all the bits have got upstream. Several
are still wending their way through maintainer trees. Feel free to send your
patch to Linus with:
Acked-by: David Howells
attac
Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > Linux 3.6 builds fine. I can't use "git bisect" until Linux 3.7-rc6 but
> > possibly caused by either commit 10b63956 "UAPI: Plumb the UAPI Kbuilds
> > into the user header installation and checking" or commit 40f1d4c2 "UAPI:
> > Remove the objhdr-y e
Cesar Eduardo Barros wrote:
> I think I will wait for your patch. Since you probably created it with the
> same scripts used for the original move to uapi/, it should have less chance
> of mistakes than my ad-hoc shell scripting.
I haven't scripted it.
David
--
To unsubscribe from this list: se
Miklos Szeredi wrote:
> > BTW, I wonder what's the right locking for that sucker; overlayfs is
> > probably too heavy - we are talking about copying a file from one fs to
> > another, which can obviously take quite a while, so holding ->i_mutex on
> > _parent_ all along is asking for very serious
_IRIX_SIGACTION.
Signed-off-by: David Howells
cc: Al Viro
cc: Ralf Baechle
cc: linux-m...@linux-mips.org
cc: sta...@vger.kernel.org
---
arch/mips/include/asm/signal.h |2 +-
include/linux/compat.h |4 ++--
include/linux/signal.h |4 ++--
3 files changed, 5 insertions(
Steven Rostedt wrote:
> Why? If we remove the tracepoint from the slowpath and use a table swap,
> then we wouldn't need to use the slowpath at all.
How are you engineering a table swap? Do you patch the system call code to
change the immediate address loaded or do you put in a level of indirec
Stephen Rothwell wrote:
> David, if I do remove it, are there other patches in your pekey tree that
> are still going forward?
No.
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:
Al Viro wrote:
> fs/cachefiles/rdwr.c:967: ret = file->f_op->write(
>
> cachefiles_write_page(); no fucking idea what locks might be held by caller
> and potentially that's a rather nasty source of PITA
The caller of cachefiles_write_page() (ie. fscache_write_op()) holds n
David Howells wrote:
> Stephen Rothwell wrote:
>
> > David, if I do remove it, are there other patches in your pekey tree that
> > are still going forward?
>
> No.
Well, maybe. But feel free to drop it anyway for the moment.
David
--
To unsubscribe from
Srivatsa S. Bhat wrote:
> We can use global rwlocks as shown below safely, without fear of deadlocks:
>
> Readers:
>
> CPU 0CPU 1
> -- --
>
> 1.spin_lock(&random_lock); read_lock(&my_rwlock)
git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git review-unify-dump
>
> While this patch touches a lot of archs, it isn't too likely to cause
> non-trivial conflicts with arch-specfic changes and would probably be
> best to route together either thr
CAI Qian wrote:
> Just booted the latest mainline,
>
> [ 35.217698] Request for unknown module key 'Magrathea: Glacier signing
> key: 8b7774b08bc4ee9637073434c10f0823f6fbe523' err -11
Can you check back earlier in the dmesg to see whether the kernel tried to
load the key? -11 is presumably -
Sarah Sharp wrote:
> I guess my question is a deeper one: do we need to rename all the xHCI
> macros to have the XHCI_ prefix, in order to avoid future collision?
> For example, one of the macros is MAX_HC_PORTS, which could possibly be
> used by other host drivers in the future.
Hmmm...
I susp
CAI Qian wrote:
> > Can you check back earlier in the dmesg to see whether the kernel tried to
> > load the key? -11 is presumably -EAGAIN - in which case no such key was
> > found
> > (rather than there being a cached lookup failure which is what -ENOKEY would
> > indicate). It is possible tha
Rusty Russell wrote:
> > I think this bit should be waved in front of Rusty. It looks like it
> > might be a bug in error handling code.
>
> It does look like it, but I can't see it. The module code doesn't see
> an error (presumably sig_enforce is false), so we continue processing
> the modul
Kasatkin, Dmitry wrote:
> What about the case when running from integrity protected initramfs?
> Either embedded into the signed kernel, or verified by the boot loader.
> In such case it is possible to assume that all keys which are added by
> user space are implicitly trusted.
> Later on, before
James Hogan wrote:
> > BTW looking at metag port, it seems that does #include
> > , but latter doesn't exist in the repository - is it
> > generated for you James or is this same issue which David elucidated to
> > above ?
>
> We have generic-y += setup.h in arch/metag/include/uapi/asm/Kbuild f
Michel Lespinasse wrote:
> Update the frv arch_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse
> Acked-by: Rik van Riel
Acked-by: David Howells
--
To unsubscribe from this list
Michal Marek wrote:
> Signed-off-by: Michal Marek
Add a check into the script to make sure that CONFIG_MODULE_SIG_HASH is
actually set to something, and then you can add "Acked-by: David Howells
".
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
Michal Marek wrote:
> -mod_sign_cmd = perl $(srctree)/scripts/sign-file $(MODSECKEY) $(MODPUBKEY)
> +mod_sign_cmd = perl $(srctree)/scripts/sign-file -a
> $(CONFIG_MODULE_SIG_HASH) $(MODSECKEY) $(MODPUBKEY)
It's mandatory, so it shouldn't really have a "-a" flag.
David
--
To unsubscribe from t
Michal Marek wrote:
> +our ($opt_v, $opt_a);
Should this be 'our' or 'my'?
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 FA
+die "Can't read private key\n" if !$signature_file && !-r $private_key;
+die "Can't read signature file\n" if $signature_file && !-r $signature_file;
Please bracket the if condition.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
Michal Marek wrote:
> >> +our ($opt_v, $opt_a);
> >
> > Should this be 'our' or 'my'?
>
> These are global variables set by getopts(), so they need to be declared
> 'our'. But I can change it to use the two-argument version of getopts,
> that does not use global variables.
No, that's fine. Pe
---
> v2: Use two-argument version of getopts to avoid global variables
> Use parentheses in EXPR if (...) constructs
Feel free to add:
Acked-by: David Howells
to your patches.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Kyle McMartin wrote:
> After thinking about it a while, this seems like the best way to solve
> the problem, although it does still kind of offend my delicate
> sensibilities...
>
> Doing this check in the crypto layer seems kind of like a layering
> violation to me (and, to be honest, I think i
Lucas De Marchi wrote:
> Callers of call_usermodehelper_fns() should check the return value and
> free themselves the data passed if the return is -ENOMEM. This is
> because the subprocess_info is allocated in this function, and if the
> allocation fail, the cleanup function cannot be called.
>
Florian Weimer wrote:
> Seriously, folks, can we go back one step and discuss what problem you
> are trying to solve? Is it about allowing third-party kernel modules
> in an environment which does not allow unsigned ring 0 code execution?
Let me try and lay things out:
(1) Like it or not, th
Bjorn Helgaas wrote:
> David, can you point me at a description of include/uapi ... what is
> there and why, and how we should decide what new things go in
> include/uapi/linux/pci.h as opposed to include/linux/pci.h? Maybe
> there should be something in Documentation/?
Probably in CodingStyle,
Greg KH wrote:
> > (6) To maintain secure boot mode, the kernel must be signed and the boot
> > loader must check the signature on it. The key must be either compiled
> > into the bootloader (and thus validated by the bootloader signature) or
> > must reside in the UEFI database.
Linus Torvalds wrote:
> > Your fix is compiling, running and yielding the correct results -
> > apologies about that.
> >
> > Acked-by: Mathieu Poirier
>
> Ok, good. Committed and pushed out. Adding rmk and dhowells to the cc
> just to let them know, since Dave said they were debugging this on
is due to the patch not having sufficient
lines of context to distinguish the two places of application.
So revert the second application of the patch.
Signed-off-by: David Howells
cc: Jiri Kosina
cc: Andrew Morton
---
security/keys/process_keys.c |2 ++
1 file changed, 2 insertions(+)
g the loop for calculate the length.
> - Removed the comment of check vlen.
>
> Cc: Rusty Russell
> Cc: Josh Boyer
> Cc: Randy Dunlap
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Signed-off-by: Chun-Yi Lee
Acked-by: David Howells
--
To unsubscribe from t
the extra deletion, the
presence of a negative key in the thread keyring (causing ENOKEY) is
incorrectly overridden by an error searching the process keyring.
So revert the second application of the patch.
Signed-off-by: David Howells
cc: Jiri Kosina
cc: Andrew Morton
cc: sta...@vger.
2012-12-20
--------
David Howells (1):
UAPI: (Scripted) Disintegrate include/video
include/uapi/video/Kbuild| 3 +
include/uapi/video/edid.h| 9 ++
include/uapi/video/sisfb.h | 209 +++
include/uapi/video/uvesa
> +ifneq ($(shell pwd), $(srctree))
How reliable is this, I wonder?
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 ht
red -Bsymbolic $(CRT0) $< -o
$@ \
-L /usr/lib64 -lefi -lgnuefi \
-L /usr/lib/gcc/x86_64-redhat-linux/4.7.2 -lgcc
pekey.o: pekey.c Makefile
$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@
Signed-off-by: David Howells
---
The followi
Linus Torvalds wrote:
> > There's only one signing authority, and they only sign PE binaries.
>
> If Red Hat wants to deep-throat Microsoft, that's *your* issue. That
> has nothing what-so-ever to do with the kernel I maintain. It's
> trivial for you guys to have a signing machine that parses t
Andrew Morton wrote:
> James has acked it. I have it queued for processing so it isn't lost.
> It has no cc:stable's in it, but David always forgets that ;)
Hmmm... I did try and resend it there on the 7th. My mail client records
that it did so, but I don't see it in the list archive and I d
Sedat Dilek wrote:
> what's the status of union-mount?
It's being reengineered again to take account of VFS changes that went in in
the last merge window.
> Where does the development happen - in [1]?
On a git tree on my PC - which is occasionally mirrored in [1] when I've got
it working.
Dav
used for module
signing, so do we really need them?
Signed-off-by: David Howells
cc: David Woodhouse
cc: Rusty Russell
cc: Josh Boyer
cc: Alexander Holler
cc: sta...@vger.kernel.org
---
crypto/asymmetric_keys/x509.asn1 |4 +-
crypto/asymmetric_keys/x509_cert_parser.c |
Miklos Szeredi wrote:
> Export do_splice_direct() to modules. Needed by overlay filesystem.
Apparently you cannot call this from any function that is holding an i_mutex
if the target of the splice uses generic_file_splice_write().
The problem is a potential deadlock situation:
We have places
Lucas De Marchi wrote:
> Or let the magic string as the last thing in the module and store the
> signature length, too. In this case no scanning is needed
Indeed. This is the better way.
The main problem is rendering the length from a shell script. It's trivial to
do as ASCII (there's a print
Hi Herbert, Rusty,
I've redone my crypto keys patches to be more specific, implementing an
asymmetric key type for containing the stuff required for public-key
cryptography and anything else one might want an asymmetric key for.
This facility can be used for module signing, firmware signing and
ed in
using it.
Signed-off-by: David Howells
Cc: David S. Miller
Cc: Dmitry Kasatkin
Cc: Arnd Bergmann
---
include/asm-generic/bitops/count_zeros.h | 57
lib/mpi/longlong.h | 138 --
lib/mpi/mpi-bit.c|
In-source documentation for the asymmetric key type. This will be located in:
Documentation/crypto/asymmetric-keys.txt
Signed-off-by: David Howells
---
Documentation/crypto/asymmetric-keys.txt | 312 ++
1 file changed, 312 insertions(+)
create mode
passed in *prep, whether or not it was preparsed.
Signed-off-by: David Howells
---
Documentation/security/keys.txt | 50 +
fs/cifs/cifs_spnego.c|6 +-
fs/cifs/cifsacl.c|8 +-
include/keys/user-type.h
e);
+}
+EXPORT_SYMBOL_GPL(unregister_asymmetric_key_parser);
+
/*
* Module stuff
*/
diff --git a/include/keys/asymmetric-parser.h b/include/keys/asymmetric-parser.h
new file mode 100644
index 000..09b3b48
--- /dev/null
+++ b/include/keys/asymmetric-parser.h
@@ -0,0 +1,37 @@
+/* Asymmetric pub
Add a subtype for supporting asymmetric public-key encryption algorithms such
as DSA (FIPS-186) and RSA (PKCS#1 / RFC1337).
Signed-off-by: David Howells
---
crypto/asymmetric_keys/Kconfig |8 +++
crypto/asymmetric_keys/Makefile |2 +
crypto/asymmetric_keys/public_key.c | 108
Reinstate and export mpi_cmp() and mpi_cmp_ui() from the MPI library for use by
RSA signature verification as per RFC3447 section 5.2.2 step 1.
Signed-off-by: David Howells
---
lib/mpi/Makefile |1 +
lib/mpi/mpi-cmp.c | 70 +
2 files
Implement RSA public key cryptography [PKCS#1 / RFC3447]. At this time, only
the signature verification algorithm is supported. This uses the asymmetric
public key subtype to hold its key data.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/Kconfig |7 +
crypto
code.
Thanks to Tomas Mraz and Miloslav Trmac for help.
Signed-off-by: Milan Broz
Signed-off-by: David Howells
---
crypto/asymmetric_keys/rsa.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
ecode
would be produced or more than 256 actions have been specified as it uses
8-bit jump values and action indices to keep space usage down.
Signed-off-by: David Howells
---
include/linux/asn1.h | 67 ++
include/linux/asn1_ber_bytecode.h | 87 ++
init/Kc
void *, size_t);
This is useful for reading ASN.1 integer primitives where the length is encoded
in the ASN.1 metadata.
Signed-off-by: David Howells
---
include/linux/mpi.h |1 +
lib/mpi/mpicoder.c | 55 +++
2 files changed, 56 insertions
b/crypto/asymmetric_keys/x509_cert_parser.c
new file mode 100644
index 000..cdcfce8
--- /dev/null
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -0,0 +1,503 @@
+/* X.509 certificate parser
+ *
+ * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells (dhowe...@
representing the OID if found or
OID__NR if not.
Signed-off-by: David Howells
---
include/linux/oid_registry.h | 90 ++
lib/.gitignore |2
lib/Kconfig |5 +
lib/Makefile | 16 +++
lib/build_OID_registry | 209
ested construct. Similarly, the decoder is limited to a maximum of 10 levels
of constructed data outside of a leaf node also in an effort to keep stack
usage down.
These restrictions can be raised if necessary.
Signed-off-by: David Howells
---
include/linux/asn1_decoder.h | 24 ++
lib/Mak
calls the first on the data held
therein:
int sprint_OID(enum OID oid, char *buffer, size_t bufsize);
Signed-off-by: David Howells
---
include/linux/oid_registry.h |2 +
lib/oid_registry.c | 81 ++
2 files changed, 83 insertions
d that the signature algorithm
matches the key algorithm.
Signed-off-by: David Howells
---
crypto/asymmetric_keys/Makefile|2 +
crypto/asymmetric_keys/signature.c | 49
include/crypto/public_key.h|4 +++
3 files changed, 54 insertions(+),
algorithms.
Possibly, this would be better as "public_key" - but that has the disadvantage
that "public key" is an overloaded term.
Signed-off-by: David Howells
---
crypto/Kconfig |1
crypto/Makefile |1
Chuck Lever <[EMAIL PROTECTED]> wrote:
> >>> +struct nfs_fh_auxdata {
> >>> + struct timespec i_mtime;
> >>> + struct timespec i_ctime;
> >>> + loff_t i_size;
> >>> +};
> >>
> >> It might be useful to explain here why you need to supplement the
> >> mtime, ctime, and size fields that alre
How about this patch?
David
---
IGET: Fix isofs_get_block() to only return 0 on success.
From: David Howells <[EMAIL PROTECTED]>
Fix isofs_get_block() to return only 0 on success. It shouldn't return a +ve
block count for example.
Also make sure that isofs_get_blocks() doesn
Rusty Russell wrote:
> Right. I think we need to use different names for generated vs supplied
> files
The problem with supplied files is people who do allyesconfig, allmodconfig
and randconfig just to test things finding that their builds break. The
kernel build magic is not really set up to
Catalin Marinas wrote:
> There is arm64 that got merged, so its headers need splitting as well.
> I'm happy to send a pull request myself just for arm64 if you give me
> the script, otherwise you can run you script again close to -rc1 (and
> I'll test it).
I can just re-run my scripts and post a
Linus Torvalds wrote:
> At the KS you said you'd be able to split this up into a preparatory
> patch. That doesn't seem to have happened.
I've been generating a tag at the preparatory patch set point for quite a
while now. If you look in the tags list on:
http://git.infradead.org/users
sconfig against x86_64, allmodconfig
against i386 and a scattering of additional defconfigs of other arches.
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
Acked-by: Thomas Gleixner
Acked-by: Michael Kerrisk
Acked-by: Paul E. McKenney
Acked-by: Dave Jones
Acked-by: H. Peter Anvin
--
ue of simplifying the logic.
(2) Break apart some cpp conditionals that got added with the arm64 arch that
are of the form:
defined(__KERNEL__) && defined(X)
Splitting these into two separate nested conditionals makes scripting
easier.
David
---
David Howells (2
Split compound conditionals containing __KERNEL__ in Arm64 where possible to
make it easier for the UAPI disintegration scripts to handle them.
Signed-off-by: David Howells
Acked-by: Catalin Marinas
---
arch/arm64/include/asm/hwcap.h |4 +++-
arch/arm64/include/asm/stat.h |4
|
defined(__SYSCALL)
include/asm-generic/unistd.h:#if !defined(_ASM_GENERIC_UNISTD_H) ||
defined(__SYSCALL)
On the assumption that the guards' ineffectiveness has passed unnoticed, just
remove these guards entirely.
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
Acked-by:
Linus Torvalds wrote:
> Ok, as usual I actually wanted to do the merge myself despite the
> annoying conflicts (this *really* is the last time I will ever accept
> any header file "cleanups" - they simply aren't worth the pain).
There was a reason I asked you to pull the patches at the *end* of
David Howells wrote:
> Linus Torvalds wrote:
>
> > Ok, as usual I actually wanted to do the merge myself despite the
> > annoying conflicts (this *really* is the last time I will ever accept
> > any header file "cleanups" - they simply aren't worth the
Geert Uytterhoeven wrote:
> > include/linux/libfdt.h | 4 +-
>
> So what happened here?
>
> -#include "../../scripts/dtc/libfdt/fdt.h"
> -#include "../../scripts/dtc/libfdt/libfdt.h"
> +#include <>
> +#include <>
I didn't expect 'system' header files to be outside o
ells/linux-headers.git
disintegrate-asm-generic
for you to fetch changes up to 8a1ab3155c2ac7fbe5f2038d6e26efeb607a1498:
UAPI: (Scripted) Disintegrate include/asm-generic (2012-10-04 18:20:15 +0100)
--------
David Howells (5):
UAP
ells/linux-headers.git disintegrate-arm64
for you to fetch changes up to ae4f6c65798014d5d7a88d03e58faba53c0a92e1:
UAPI: (Scripted) Disintegrate arch/arm64/include/asm (2012-10-04 18:20:24
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-hexagon
for you to fetch changes up to 0ee1d088b96a538a1c2572078283452ef39634fc:
UAPI: (Scripted) Disintegrate arch/hexagon/include/asm (2012-10-04 18:20:45
+0100)
--------
David Howells (6):
UAPI: Fix
ells/linux-headers.git
disintegrate-microblaze
for you to fetch changes up to 7ca55698c6fdfabad768cd10f1a8a73bf2c705b6:
UAPI: (Scripted) Disintegrate arch/microblaze/include/asm (2012-10-04
18:21:00 +0100)
--------
David Howells (6):
ells/linux-headers.git disintegrate-parisc
for you to fetch changes up to 36141239e2e08d847531d4d81d5e82c10835f2d5:
UAPI: (Scripted) Disintegrate arch/parisc/include/asm (2012-10-04 18:21:12
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-h8300
for you to fetch changes up to fba22e60df0124dfb2b5b434dfb70876a6dbec8a:
UAPI: (Scripted) Disintegrate arch/h8300/include/asm (2012-10-04 18:20:42
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-m32r
for you to fetch changes up to d82734fb090c049b7e8d20fd513b48a25184e476:
UAPI: (Scripted) Disintegrate arch/m32r/include/asm (2012-10-04 18:20:52
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-openrisc
for you to fetch changes up to 8c66ec929c6979b49006c1d56148609380612d34:
UAPI: (Scripted) Disintegrate arch/openrisc/include/asm (2012-10-04 18:21:09
+0100)
--------
David Howells (6):
UAP
ells/linux-headers.git disintegrate-sparc
for you to fetch changes up to d4ae6a1549e06de45a1c8a4fb596a2874f5f83e5:
UAPI: (Scripted) Disintegrate arch/sparc/include/asm (2012-10-04 18:21:32
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-xtensa
for you to fetch changes up to 3d47e44c3c53cb397e38a459171348d9b501a66e:
UAPI: (Scripted) Disintegrate arch/xtensa/include/asm (2012-10-04 18:21:48
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-x86
for you to fetch changes up to c64630429a9d37a248c6b06a738fad838f2f5e37:
UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-10-04 18:21:45 +0100)
--------
David Howells (6):
UAPI: Fix the guards
ells/linux-headers.git disintegrate-tile
for you to fetch changes up to 103dc5f6e03fde83c912e779656b1276c661c3a7:
UAPI: (Scripted) Disintegrate arch/tile/include/asm (2012-10-04 18:21:37
+0100)
--------
David Howells (7):
UAPI: Fix the
ells/linux-headers.git disintegrate-sh
for you to fetch changes up to c7d4fbbc3985e65500dc73c241284a19e968fc04:
UAPI: (Scripted) Disintegrate arch/sh/include/asm (2012-10-04 18:21:28 +0100)
--------
David Howells (6):
UAPI: Fix the guards on v
ells/linux-headers.git disintegrate-powerpc
for you to fetch changes up to d4b1059feb6486ae0800e936b9dd5fd4e05b9d0c:
UAPI: (Scripted) Disintegrate arch/powerpc/include/asm (2012-10-04 18:21:17
+0100)
--------
David Howells (6):
UAPI: Fix
ells/linux-headers.git disintegrate-mips
for you to fetch changes up to 49c611211de4006faefba4ea9a4219ed97f71707:
UAPI: (Scripted) Disintegrate arch/mips/include/asm (2012-10-04 18:21:03
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git
disintegrate-unicore32
for you to fetch changes up to 865a0cb9fdb8a38eea9aa5d8c9ebb9ce2c49d6ba:
UAPI: (Scripted) Disintegrate arch/unicore32/include/asm (2012-10-04 18:21:39
+0100)
--------
David Howells (6):
UAP
ells/linux-headers.git disintegrate-alpha
for you to fetch changes up to d83954c803730c2eed1a099dbd2fcf053cdd4b07:
UAPI: (Scripted) Disintegrate arch/alpha/include/asm (2012-10-04 18:20:19
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-c6x
for you to fetch changes up to aba4895a9a323c89d70cd219356414cf93371348:
UAPI: (Scripted) Disintegrate arch/c6x/include/asm (2012-10-04 18:20:30 +0100)
--------
David Howells (6):
UAPI: Fix the guards
ells/linux-headers.git disintegrate-arm
for you to fetch changes up to 4d192d7a0633e8eb4952996dc12af3832968e43a:
UAPI: (Scripted) Disintegrate arch/arm/include/asm (2012-10-04 18:20:22 +0100)
--------
David Howells (6):
UAPI: Fix the guards
ells/linux-headers.git disintegrate-score
for you to fetch changes up to 4120c854c24a10e928db23d65395c4c6dac168b6:
UAPI: (Scripted) Disintegrate arch/score/include/asm (2012-10-04 18:21:25
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-m68k
for you to fetch changes up to b039235da939b28c539b3e1b4566107a9bdbdef8:
UAPI: (Scripted) Disintegrate arch/m68k/include/asm (2012-10-04 18:20:56
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-blackfin
for you to fetch changes up to d65fee76eb053476a6eddd870d067469874c1ddf:
UAPI: (Scripted) Disintegrate arch/blackfin/include/asm (2012-10-04 18:20:29
+0100)
--------
David Howells (6):
UAP
ells/linux-headers.git disintegrate-cris
for you to fetch changes up to 4816d1b7a51526bc4722731d5516c295a9c72a1c:
UAPI: (Scripted) Disintegrate arch/cris/include/asm (2012-10-04 18:20:35
+0100)
--------
David Howells (8):
UAPI: Fix the
ells/linux-headers.git disintegrate-avr32
for you to fetch changes up to b1118be90af0ea0a847d38416304d9596f9ea0f0:
UAPI: (Scripted) Disintegrate arch/avr32/include/asm (2012-10-04 18:20:27
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-ia64
for you to fetch changes up to f68301fee71510300140990c4e7a2769801fbd70:
UAPI: (Scripted) Disintegrate arch/ia64/include/asm (2012-10-04 18:20:49
+0100)
--------
David Howells (6):
UAPI: Fix the
ells/linux-headers.git disintegrate-s390
for you to fetch changes up to e06141872cc97d8b8cafc1d02d325f7e0f752ce4:
UAPI: (Scripted) Disintegrate arch/s390/include/asm (2012-10-04 18:21:21
+0100)
--------
David Howells (6):
UAPI: Fix the
David Miller wrote:
> When I pull the sparc branch, I get c6x and arm64 commits too.
>
> 37d11ab8b478ccb7aa227003ca2e5ac4c11d
> 1c1e436269fe840cdbecfaf397b21778dd276f26
>
> I don't want that going in via the sparc tree, it really
> doesn't belong there.
They're at the base of every branch
m_para.h on
m68k) (2012-10-04 18:16:47 +0100)
(from the branch description for uapi-prep local branch)
clone of "master"
--------
David Howells (4):
UAPI: Fix the guards o
Geert Uytterhoeven wrote:
> I assume these c6x and asm-generic changes are the ones you just asked Linus
> to pull?
Yes.
> Doesn't it make more sense to ask us (the individual arch maintainers) to
> pull our parts after Linus has pulled the generic part?
I suppose so.
> Do you want this ("our
1 - 100 of 7895 matches
Mail list logo
