Per the post here:
http://lkml.org/lkml/2007/6/18/228
it appears that the group ownership patch has made it into .23. I am
using these patches, amongst which the kernel component appears to be
identical:
http://sigxcpu.org/unsorted-patches/0001-allow-tun-ownership-by-group.patch
On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
[EMAIL PROTECTED] wrote:
It will become even *more* of a "not that common" if the lock will
block moves and ACL changes *across the filesystem* for
potentially *minutes* at a time.
It will not take anywhere NEAR minutes at a time to update
On Fri, Aug 17, 2007 at 05:03:41PM -0700, Stephen Hemminger wrote:
> On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
> Kevin E <[EMAIL PROTECTED]> wrote:
>
> > Hi all,
> >
> > I've read where the onboard Marvell lan controller on
> > some Gigabyte boards don't work. I've got two systems
> > using
On Fri, Aug 17, 2007 at 06:24:17PM +0200, Xu Yang wrote:
> Hi everyone,
>
> I have built up a software virtual prototype system with ARM11MPCORE.
> my system is similar with realview_eb_mpcore. but my system is
> simpler, which has only a mpcore , uart0, console,timer0_1, and
> memorys.
>
> I
On Fri, Aug 17, 2007 at 11:34:37AM -0700, K Naru wrote:
> From: Kim Naru ([EMAIL PROTECTED])
>
> Added support to offload TCP/UDP/IP checksum to the
> VIA Technologies VT6105M chip.
> Firstly, let the stack know this chip is capable of
> doing its own checksum(IPV4 only).
> Secondly offload
Finally moved back in and with internet. Yay!
On Aug 17, 2007, at 00:56:44, Casey Schaufler wrote:
It would not surprise me particularly much if Kyle or someone like
him could produce a perl script that could generate an SELinux
policy that, when added to the reference policy on a system
> This is also a series of falsehoods. All packet filtering,
> queue management, and packet scheduling facilities work perfectly
> fine and as designed with both LRO and TSO.
I'm not sure I follow. Perhaps "broken" was too strong a word to use,
but if you pass a huge segment to a NIC with
On Thu, Aug 16, 2007 at 09:23:48PM +0100, Alan Cox wrote:
> On Thu, 16 Aug 2007 19:50:43 +0200
> Authenticated <[EMAIL PROTECTED]> wrote:
>
> >
> > ===
> > [ INFO: possible circular locking dependency detected ]
> > 2.6.20-1.2948.self #1
> >
The documentation simply doesn't say "+m" is allowed. The code to
allow it was added for the benefit of people who do not read the
documentation. Documentation for "+m" might get added later if it
is decided this [the code, not the documentation] is a sane thing
to have (which isn't directly
Hi Christoph,
When I force SLUB debugging on sparc64, it barfs on early bootup while
making the sysfs nodes. Removing the BUG()'s on the sysfs error
returns, and adding some tracing I captured the log below.
BTW, I would recommending removing the BUG() calls, they serve only to
force someone
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 20:31:39 -0700
> On Fri, 17 Aug 2007 18:57:00 -0700
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> > > On Fri, 17 Aug 2007 18:49:34 -0700
> > > Arjan van de
Add a easier method to find maintainers to CC for a patch
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
Changes since last submittal:
Added options to include|ignore penguin-chiefs
Changed defaults to appropriate for git-send-email
Added optional git signed-off-by: checking
Changed syntax to
On Sat, 18 Aug 2007, Satyam Sharma wrote:
>
> No code does (or would do, or should do):
>
> x.counter++;
>
> on an "atomic_t x;" anyway.
That's just an example of a general problem.
No, you don't use "x.counter++". But you *do* use
if (atomic_read() <= 1)
and loading into a
On Friday 17 August 2007, Kay Sievers wrote:
>
> > I'm not the one who's advocating a change here. If you want to
> > first change/break and then fix things, all of that is up to you.
>
> I'm happy to do that. Patch is attached.
NAK. That wasn't even a serious attempt at the "fix" part,
[Jesper Juhl - Sat, Aug 18, 2007 at 12:17:33AM +0200]
| On 17/08/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
| >
| > The patch titled
| > CIFS: check for granted memory
| > has been added to the -mm tree. Its filename is
| > cifs-check-for-granted-memory.patch
| >
| > *** Remember
On Fri, 17 Aug 2007 18:57:00 -0700
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> > On Fri, 17 Aug 2007 18:49:34 -0700
> > Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Fri, 2007-08-17 at 16:50 -0700, Stephen
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> On Fri, 17 Aug 2007, Mathieu Desnoyers wrote:
>
> > Actually, get_cycles() at least on some AMD cpus, do not synchronize the
> > core, which can skew the results. You might want to use
> > get_cycles_sync() there.
>
> get_cycle() results as used
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > The "asm volatile" implementation does have exactly the same
> > > > > reordering guarantees as the "volatile cast" thing,
> > > >
> > > > I don't think so.
> > >
> > > "asm volatile" creates a side effect.
> >
> > Yeah.
> >
> > >
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> On Fri, 17 Aug 2007, Mathieu Desnoyers wrote:
>
> > Why do you printk inside the timing period ? Filling the printk buffers
> > or outputting on things such as serial console could really hurt your
> > results.
>
> It was easier to code?
>
> > I
Matt,
On Fri, Aug 17, 2007 at 11:58:08AM -0500, Matt Mackall wrote:
> On Fri, Aug 17, 2007 at 02:47:27PM +0800, Fengguang Wu wrote:
> > It's not easy to do direct performance comparisons between pmaps and
> > pagemap/kpagemap. However some close analyzes are still possible :)
> >
> > 1) code
On Fri, 2007-08-17 at 12:50 -0700, David Brownell wrote:
> On Friday 17 August 2007, Kay Sievers wrote:
> > On Fri, 2007-08-17 at 09:55 -0700, David Brownell wrote:
> > >
> > > If so, then whoever tried to change the usage of module aliases
> > > in that way goofed in several ways. First, by
The "asm volatile" implementation does have exactly the same
reordering guarantees as the "volatile cast" thing,
I don't think so.
"asm volatile" creates a side effect.
Yeah.
Side effects aren't
allowed to be reordered wrt sequence points.
Yeah.
This is exactly
the same reason as why
On Fri, 17 Aug 2007, Nick Piggin wrote:
> Satyam Sharma wrote:
>
> > I didn't quite understand what you said here, so I'll tell what I think:
> >
> > * foo() is a compiler barrier if the definition of foo() is invisible to
> > the compiler at a callsite.
> >
> > * foo() is also a compiler
On Fri, 2007-08-17 at 18:54 -0700, Stephen Hemminger wrote:
> On Fri, 17 Aug 2007 18:49:34 -0700
> Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> > > Tne network code does memset for 6 and 8 byte values, that can easily
> > >
On Fri, 17 Aug 2007 18:49:34 -0700
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> > Tne network code does memset for 6 and 8 byte values, that can easily
> > be optimized into simple assignments without string instructions.
>
>
>
On Fri, 2007-08-17 at 16:50 -0700, Stephen Hemminger wrote:
> Tne network code does memset for 6 and 8 byte values, that can easily
> be optimized into simple assignments without string instructions.
so... question.
Why are we doing this by hand? Wouldn't gcc just generate this code in
the
On Fri, 2007-08-17 at 16:38 -0700, Junio C Hamano wrote:
> Joe Perches <[EMAIL PROTECTED]> writes:
> ... Signed-off-by: ...
> I do not see a patch to "Documentation/git-send-email.txt" here...
> Something like this, with appropriate error checking, perhaps?
>
> open my $cc, "${cc_cmd} $t
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > > atomic_dec() writes
> > > > > to memory, so it _does_ have "volatile semantics", implicitly, as
> > > > > long as the compiler cannot optimise the atomic variable away
> > > > > completely -- any store counts as a side effect.
> > > >
>
Instead, use asm() like all other atomic operations already do.
+static __inline__ long atomic64_read(const atomic_t *v)
+static __inline__ void atomic64_set(atomic_t *v, long i)
s/atomic_t/atomic64_t/ in both lines. I've edited my copy of the
patch.
Ouch, sorry about that.
Segher
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Paul E. McKenney wrote:
>
> > On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> > > On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> > > >
> > > > gcc bugzilla bug #33102, for whatever that ends
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
> On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> > On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> > >
> > > gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
> >
> > I had totally forgotten that
On Sat, Aug 18, 2007 at 08:09:13AM +0800, Herbert Xu wrote:
> On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
> >
> > gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
>
> I had totally forgotten that I'd already filed that bug more
> than six years ago until
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
> If yes, who invented this 1980s reminiscence, where you got valid
> pointers for malloc(0) ?
I believe his first name started with an L and ended with an s ;-)
Seriously the kmalloc(0) pointer allowed us to detect cases in which
people tried to
Get rid of an empty if statement which might look like a bug to a
casual reader.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
fs/hostfs/hostfs_user.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.22/fs/hostfs/hostfs_user.c
Style fixes in hostfs.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
fs/hostfs/hostfs.h |9 +
fs/hostfs/hostfs_kern.c | 226
fs/hostfs/hostfs_user.c | 139 +
3 files changed, 202 insertions(+), 172
The BLKGETSIZE ioctl expects a pointer to a long, os_file_size was providing
an int. Therefore, ubd access to host block devices caused a segmentation
fault on 64 bits systems.
Signed-off-by: Nicolas George <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
"extern inline" will have different semantics with gcc 4.3.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
include/asm-um/pgalloc.h |2 +-
include/asm-um/pgtable-3level.h |2 +-
include/asm-um/processor-x86_64.h |2 +-
A number of files that were changed in the recent removal of tt mode
are userspace files which call the os_* wrappers instead of calling
libc directly. A few other files were affected by this, through
This patch makes these call glibc directly.
There are also style fixes in the affected areas.
Tidy the tlb flushing code.
With tt mode gone, there is no reason to have the capability to have
different host-level address space updating routines. So, do_op is
called directly from do_mmap, do_mprotect, and do_munmap, rather than
calling a function pointer that it is given.
There was a
These patches are 2.6.24 material.
They are code cleanup, plus a minor bug fix.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Add a new parameter "dmaflush" to ib_umem_get, and update all
callers. For now only the mthca IB driver makes use of the new
parameter.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
drivers/infiniband/core/umem.c |8 ++--
Joe Perches <[EMAIL PROTECTED]> writes:
> Here's a path to enable a command line option
> that takes a string argument
>
> cc-cmd
>
> This modifies the @cc array to include whatever
> output is produced by cc_cmd $patchfile
>
> cccmd can be stored in a config settings file
>
> previous
Introduce a no-op stub function "dma_flags_set_dmaflush". Arches
can override this if necessary to associate a "dmaflush" attribute
with a DMA-able memory region. In-flight DMA will be flushed to
host memory when a memory region with the dmaflush attribute is
written to.
Signed-off-by: Arthur
Define ARCH_DOES_POSTED_DMA, and override the dma_flags_set_dmaflush
function. Also define dma_flags_get_direction, dma_flags_get_dmaflush
to retrieve the direction and "dmaflush attribute" from flags
passed to the sn_dma_map_* functions.
Signed-off-by: Arthur Kepner <[EMAIL PROTECTED]>
--
Altix supports "posted DMA", so that DMA may complete out
of order. In some cases it's necessary for a driver to
ensure that in-flight DMA has been flushed to memory for
correct operation.
In particular this can be a problem with Infiniband, where
writes to Completion Queues can race with
No it does not have any volatile semantics. atomic_dec() can be
reordered
at will by the compiler within the current basic unit if you do not
add a
barrier.
"volatile" has nothing to do with reordering.
If you're talking of "volatile" the type-qualifier keyword, then
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> This patch breaks Xen booting. I get infinite recursive faults during
> patching when this patch is present. If I boot with
> "noreplace-paravirt" it works OK, and it works as expected if I back
> this patch out. I haven't tracked down the
On Fri, Aug 17, 2007 at 04:59:12PM -0700, Paul E. McKenney wrote:
>
> gcc bugzilla bug #33102, for whatever that ends up being worth. ;-)
I had totally forgotten that I'd already filed that bug more
than six years ago until they just closed yours as a duplicate
of mine :)
Good luck in getting
atomic_dec() writes
to memory, so it _does_ have "volatile semantics", implicitly, as
long as the compiler cannot optimise the atomic variable away
completely -- any store counts as a side effect.
I don't think an atomic_dec() implemented as an inline "asm volatile"
or one that uses a "forget"
Andi Kleen wrote:
> Commit 19d36ccdc34f5ed444f8a6af0cbfdb6790eb1177 "x86: Fix alternatives
> and kprobes to remap write-protected kernel text" uses code which is
> being patched for patching.
>
> In particular, paravirt_ops does patching in two stages: first it
> calls paravirt_ops.patch, then it
On Fri, 17 Aug 2007 05:42:13 -0700 (PDT)
Kevin E <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've read where the onboard Marvell lan controller on
> some Gigabyte boards don't work. I've got two systems
> using the same Gigabyte board, on one the LAN works on
> the other it dies like
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 16:31:07 -0700
> > > > When using RDMA you lose the capability to do packet shaping,
> > > > classification, and all the other wonderful networking facilities
> > > > you've grown to love and use over the years.
> > >
> > >
For those interested, an updated PS3 Linux Distributor's Starter
Kit (v1.4) was released.
The release note is here:
http://www.kernel.org/pub/linux/kernel/people/geoff/cell/CELL-Linux-CL_20070817-ADDON/README-e.txt
And the CD-ROM iso image is here (169 MiB):
On Thu, Aug 16, 2007 at 08:50:30PM -0700, Linus Torvalds wrote:
> Just try it yourself:
>
> volatile int i;
> int j;
>
> int testme(void)
> {
> return i <= 1;
> }
>
> int testme2(void)
> {
> return j <= 1;
> }
>
> and
#define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
[ This is exactly equivalent to using "+m" in the constraints, as
recently
explained on a GCC list somewhere, in response to the patch in my
bitops
series a few weeks back where I thought "+m" was bogus. ]
[It wasn't
Tne network code does memset for 6 and 8 byte values, that can easily
be optimized into simple assignments without string instructions.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/asm-i386/string.h 2007-08-17 15:14:37.0 -0700
+++ b/include/asm-i386/string.h
On Sat, 18 Aug 2007, Thomas Gleixner wrote:
> On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
> > On 8/18/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > > That was merged over my objections. IMHO ksize(NULL) should fail since we
> > > are determining the size of an unallocated
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > > > No it does not have any volatile semantics. atomic_dec() can be
> > > > reordered
> > > > at will by the compiler within the current basic unit if you do not add
> > > > a
> > > > barrier.
> > >
> > > "volatile" has nothing to do with
On Sat, 2007-08-18 at 00:42 +0300, Pekka Enberg wrote:
> On 8/18/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > That was merged over my objections. IMHO ksize(NULL) should fail since we
> > are determining the size of an unallocated object.
>
> Agreed, especially as we have real zero-sized
On Sat, 18 Aug 2007, Segher Boessenkool wrote:
> > #define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
> >
> > [ This is exactly equivalent to using "+m" in the constraints, as recently
> > explained on a GCC list somewhere, in response to the patch in my bitops
> > series a
[PATCH] serial: keep the DTR setting for serial console.
with reverting "x86, serial: convert legacy COM ports to platform devices", we
will have the serial console before the port is probled again.
uart_add_one_port==>uart_configure_port==>set_mcttrl(port, 0) will clear the
DTR setting by
Optimize uses of memset with small constant offsets.
This will generate smaller code, and avoid the slow rep/string instructions.
Code copied from i386 with a little cleanup.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/asm-x86_64/string.h 2007-08-17
> > > When using RDMA you lose the capability to do packet shaping,
> > > classification, and all the other wonderful networking facilities
> > > you've grown to love and use over the years.
> >
> > Same thing with TSO and LRO and who knows what else.
>
> Not true at all. Full
On Sat, 18 Aug 2007, Pekka Enberg wrote:
> Agreed, especially as we have real zero-sized objects returned from
> kmalloc() et al now.
Slab allocators: Fail if ksize is called with a NULL parameter
A NULL pointer means that the object was not allocated. One cannot
determine the size of an
Hi Andrew,
Thank you for comments.
Andrew Morton wrote:
>> Index: 2.6-mm/include/asm-i386/kprobes.h
>> ===
>> --- 2.6-mm.orig/include/asm-i386/kprobes.h
>> +++ 2.6-mm/include/asm-i386/kprobes.h
>> @@ -44,6 +44,7 @@ typedef u8
On Fri, Aug 17, 2007 at 02:18:56PM -0700, Andrew Morton wrote:
> Please always provide at least a copy of the error message when providing
> patches which fix warnings, or build errors, or section mismatches.
>
> For section mismatches, an analysis of what caused the problem would help,
> too.
#define forget(a) __asm__ __volatile__ ("" :"=m" (a) :"m" (a))
[ This is exactly equivalent to using "+m" in the constraints, as
recently
explained on a GCC list somewhere, in response to the patch in my
bitops
series a few weeks back where I thought "+m" was bogus. ]
[It wasn't
On Friday 17 August 2007, Robin Getz wrote:
> On Fri 17 Aug 2007 17:10, David Brownell pondered:
> > On the other hand, maybe you want your "typical" customer to
> > be more of a systems integrator than anything else.
>
> We are getting yelled at by our customers (I was on the phone yesterday),
Here, I should obviously admit that the semantics of *(volatile int
*)&
aren't any neater or well-defined in the _language standard_ at all.
The
standard does say (verbatim) "precisely what constitutes as access to
object of volatile-qualified type is implementation-defined", but GCC
does help
Now the second wording *IS* technically correct, but come on, it's
24 words long whereas the original one was 3 -- and hopefully anybody
reading the shorter phrase *would* have known anyway what was meant,
without having to be pedantic about it :-)
Well you were talking pretty formal (and
On Friday 17 August 2007, Robin Getz wrote:
> On Fri 17 Aug 2007 14:24, David Brownell pondered:
> > Just for the record, this is an unusual way to use these calls.
>
> That is part of the natural evolution of the kernel isn't it - per James's
> keynote at OLS - you release something, and see
In a reasonable world, gcc should just make that be (on x86)
addl $1,i(%rip)
on x86-64, which is indeed what it does without the volatile. But with
the
volatile, the compiler gets really nervous, and doesn't dare do it in
one
instruction, and thus generates crap like
movl
Neil Horman wrote:
>
> +static int proc_pid_limits(struct task_struct *task, char *buffer)
> +{
> + unsigned int i;
> + int count = 0;
> + char *bufptr = buffer;
> +
> + struct rlimit rlim[RLIM_NLIMITS];
> +
> + read_lock(_lock);
> + memcpy(rlim, task->signal->rlim,
(and yes, it is perfectly legitimate to
want a non-volatile read for a data type that you also want to do
atomic RMW operations on)
...which is undefined behaviour in C (and GCC) when that data is
declared volatile, which is a good argument against implementing
atomics that way in itself.
On 17/08/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> The patch titled
> CIFS: check for granted memory
> has been added to the -mm tree. Its filename is
> cifs-check-for-granted-memory.patch
>
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
>
On Fri 17 Aug 2007 17:10, David Brownell pondered:
> On the other hand, maybe you want your "typical" customer to
> be more of a systems integrator than anything else.
We are getting yelled at by our customers (I was on the phone yesterday),
because the kernel build environment we distribute
Of course, since *normal* accesses aren't necessarily limited wrt
re-ordering, the question then becomes one of "with regard to *what*
does
it limit re-ordering?".
A C compiler that re-orders two different volatile accesses that have a
sequence point in between them is pretty clearly a buggy
On Fri, 17 Aug 2007 15:43:04 -0400
Masami Hiramatsu <[EMAIL PROTECTED]> wrote:
> This patch introduces architecture dependent kretprobe
> blacklists to prohibit users from inserting return
> probes on the function in which kprobes can be inserted
> but kretprobes can not.
>
> Signed-off-by:
>-Original Message-
>From: David Brownell [mailto:[EMAIL PROTECTED]
>
>On Friday 17 August 2007, Hennerich, Michael wrote:
>> What Mike wants to point out is that a external IRQ is first a GPIO
and
>> needs to be configured like an INPUT GPIO and then a specific bit
needs
>> to be set
On Friday, 17 August 2007 23:08, Andrew Morton wrote:
> On Fri, 17 Aug 2007 15:26:22 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > During hibernation and suspend on x86_64 save CPU registers in the
> > saved_context
> > structure rather than in a handful of separate variables.
>
On Fri 17 Aug 2007 14:24, David Brownell pondered:
> Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how people [ab]use it until
it either grows, evolves,
On 8/18/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> That was merged over my objections. IMHO ksize(NULL) should fail since we
> are determining the size of an unallocated object.
Agreed, especially as we have real zero-sized objects returned from
kmalloc() et al now.
-
To unsubscribe from
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Sat, 18 Aug 2007, Satyam Sharma wrote:
>
> > Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
> > return 0).
>
> That was merged over my objections. IMHO ksize(NULL) should fail since we
> are determining the size of an
On 17/08/07, Xu Yang <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> I am trying to port kernel 2.6.19 onto my system.so I need the c code
> , which can show me where the program is running. I add -g when I
> compile it.
>
You shouldn't need to do that manually, simply go into "make
menuconfig",
On Friday 17 August 2007, Hennerich, Michael wrote:
> What Mike wants to point out is that a external IRQ is first a GPIO and
> needs to be configured like an INPUT GPIO and then a specific bit needs
> to be set unmask it as IRQ.
>
> So why not use the GPIO infrastructure to setup this pin as
On Friday 17 August 2007, Mike Frysinger wrote:
> as Michael pointed out, in the Blackfin world we tend to keep things
> very dynamic as we have dev systems which allow for dropping in of
> optional cards at will, so doing this in the bootloader is way too
> inflexible.
That's the tradeoff:
On Friday 17 August 2007, Hennerich, Michael wrote:
> Hi Dave,
>
> Right - our patch descriptions needs to be worked on.
Yes, please ... that makes reviewing easier!
> For a well experienced
> systems engineer being the same time the same guy who does the Hardware
> and the Software this
On Fri, 17 Aug 2007, Mel Gorman wrote:
> @@ -696,6 +696,16 @@ static inline struct zonelist *node_zone
> return _DATA(nid)->node_zonelist;
> }
>
> +static inline int zone_in_nodemask(unsigned long zone_addr,
> + nodemask_t *nodes)
> +{
> +#ifdef CONFIG_NUMA
>
On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
> On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> >
> > Something like:
> >
> > Index: kernel/printk.c
> > ===
> > --- kernel/printk.c (revision 3568)
> > +++ kernel/printk.c
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 12:52:39 -0700
> > When using RDMA you lose the capability to do packet shaping,
> > classification, and all the other wonderful networking facilities
> > you've grown to love and use over the years.
>
> Same thing with TSO and
Hi,
Easily avoidable compiler warnings bug me.
Building irmod without CONFIG_SYSCTL currently results in :
net/irda/irmod.c:132: warning: label 'out_err_2' defined but not used
But that can easily be avoided by simply moving the label inside
the existing "#ifdef CONFIG_SYSCTL" one line
On Sat, 18 Aug 2007, Satyam Sharma wrote:
> On Fri, 17 Aug 2007, Christoph Lameter wrote:
>
> > On Fri, 17 Aug 2007, Andrew Morton wrote:
> >
> > > are we seeing a pattern here? We could stick the unlikely inside
> > > ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there
>
On Fri, 17 Aug 2007 16:51:15 -0400
Joe Korty <[EMAIL PROTECTED]> wrote:
> Fix section mismatch in the Adaptec DPT SCSI Raid driver.
>
> Signed-off-by: Joe Korty <[EMAIL PROTECTED]>
>
> Index: 2.6.23-rc3-git1/drivers/scsi/dpt_i2o.c
>
On Sat, 18 Aug 2007, Satyam Sharma wrote:
> > page = get_object_page(object);
>
> Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
> return 0).
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
> Oh
On 8/17/07, Robin Getz <[EMAIL PROTECTED]> wrote:
> On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
> > Mike Frysinger wrote:
> > >> Hmm, sort of, although I didn't think about the case of no real console
> > >> replacing the early console. The intention of the patch is to have a
> > >> smooth
On Fri, 17 Aug 2007 15:26:22 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> During hibernation and suspend on x86_64 save CPU registers in the
> saved_context
> structure rather than in a handful of separate variables.
You have "-mm" in the subject but afaict this patch is not dependent
Hi,
I don't like compiler warnings, especially not when they are easy to
avoid.
Building cyclades driver without CONFIG_PCI currently results in this :
CC drivers/char/cyclades.o
drivers/char/cyclades.c: In function 'cy_init':
drivers/char/cyclades.c:5488: warning: label 'err_unr'
On Fri, 17 Aug 2007, Mel Gorman wrote:
> Opinions as to why FASTCALL breaks on one machine are welcome.
Could we get rid of FASTCALL? AFAIK the compiler should automatically
choose the right calling convention?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, 17 Aug 2007, Christoph Lameter wrote:
> On Fri, 17 Aug 2007, Andrew Morton wrote:
>
> > are we seeing a pattern here? We could stick the unlikely inside
> > ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
> > be future callsites at which it is likely, who
On Fri, 17 Aug 2007, Mel Gorman wrote:
> +/*
> + * SMP will align zones to a large boundary so the zone ID will fit in the
> + * least significant biuts. Otherwise, ZONES_SHIFT must be 2 or less to
> + * fit
ZONES_SHIFT is always 2 or less
Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
-
1 - 100 of 678 matches
Mail list logo
