“17a370bcca661a849c9af07feae86f42d0c6dfd1”上不存在“drivers/git@gitcode.net:openeuler/kernel.git”
- 31 5月, 2012 1 次提交
-
-
由 James Bottomley 提交于
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
-
- 27 7月, 2011 1 次提交
-
-
由 Arun Sharma 提交于
This allows us to move duplicated code in <asm/atomic.h> (atomic_inc_not_zero() for now) to <linux/atomic.h> Signed-off-by: NArun Sharma <asharma@fb.com> Reviewed-by: NEric Dumazet <eric.dumazet@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: David Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Acked-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 31 3月, 2009 1 次提交
-
-
由 Helge Deller 提交于
This patch adds the ftrace debugging functionality to the parisc kernel. It will currently only work with 64bit kernels, because the gcc options -pg and -ffunction-sections can't be enabled at the same time and -ffunction-sections is still needed to be able to link 32bit kernels. Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
- 13 6月, 2008 1 次提交
-
-
由 Kyle McMartin 提交于
Needed by fuse (via copy_highpage). Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
- 17 4月, 2008 1 次提交
-
-
由 Matthew Wilcox 提交于
Semaphores are no longer performance-critical, so a generic C implementation is better for maintainability, debuggability and extensibility. Thanks to Peter Zijlstra for fixing the lockdep warning. Thanks to Harvey Harrison for pointing out that the unlikely() was unnecessary. Signed-off-by: NMatthew Wilcox <willy@linux.intel.com> Acked-by: NIngo Molnar <mingo@elte.hu>
-
- 07 12月, 2007 1 次提交
-
-
由 Kyle McMartin 提交于
This reverts commit efb80e7e, it turned out to cause sporadic problems with the timer interrupt on 32-bit kernels. Needs more investigation. Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
- 18 10月, 2007 1 次提交
-
-
由 Kyle McMartin 提交于
Currently we're hacking libs-y to include libgcc.a, but this has unforeseen consequences since the userspace libgcc is linked with fpregs enabled. We need the kernel to stop using fpregs in an uncontrolled manner to implement lazy fpu state saves. Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
-
- 17 2月, 2007 1 次提交
-
-
由 Helge Deller 提交于
- additionally update my copyright timestamps Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
-
- 12 10月, 2006 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 11 4月, 2006 1 次提交
-
-
由 Kyle McMartin 提交于
While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't being exported from lib/string.c. Investigating further, I noticed a changeset that removed its export and added it to _ksyms.c on a few more architectures. The justification was that "other arches do it." I think this is wrong, since no architecture currently defines __HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it themselves. Therefore, consolidate the export to lib/string.c. Signed-off-by: NKyle McMartin <kyle@parisc-linux.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 31 3月, 2006 2 次提交
-
-
由 Kyle McMartin 提交于
Some symbols are exported both in parisc_ksyms.c, and at their definition site. Nuke the redundant EXPORT_SYMBOL in ksyms to quiet warnings when vmlinux is linked. Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
-
由 Kyle McMartin 提交于
Move ioremap/iounmap EXPORT_SYMBOL to ioremap.c where they belong. Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
-
- 23 1月, 2006 1 次提交
-
-
由 Kyle McMartin 提交于
Move the EXPORT_SYMBOL() of pm_power_off from parisc_ksyms.c to the location of its definition in process.c Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-