Re: Why is the kfree() argument const?

look up the rationale for that design decision (I couldn't find it). It might shed some light on this discussion. /DM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/m

Re: Why is the kfree() argument const?

couldn't find it). It might shed some light on this discussion. /DM -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [patch 2/2] track and print last unloaded module in the oops trace

only; the name comes from an already loaded > module. > If you can load kernel modules of your choice you own the entire kernel > already anway > Still, strcpy seems like a better choice IMHO. /DM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [patch 2/2] track and print last unloaded module in the oops trace

On Jan 7, 2008 12:19 AM, Arjan van de Ven <[EMAIL PROTECTED]> wrote: [...] > This patch tracks the last unloaded module, and prints this as part of the > module list in the oops trace. > [...] >} > + /* Store the name of the last unloaded module for diagnostic purposes > */ > +

Re: [patch 2/2] track and print last unloaded module in the oops trace

On Jan 7, 2008 12:19 AM, Arjan van de Ven [EMAIL PROTECTED] wrote: [...] This patch tracks the last unloaded module, and prints this as part of the module list in the oops trace. [...] } + /* Store the name of the last unloaded module for diagnostic purposes */ +

Re: [patch 2/2] track and print last unloaded module in the oops trace

module. If you can load kernel modules of your choice you own the entire kernel already anway Still, strcpy seems like a better choice IMHO. /DM -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: [RFC v2] Documentation about unaligned memory access

above will not do what you intended given the, at least as I read it, implied context of myfunc. Since data is a u8* it will only get one byte of data. To avoid misunderstandings the code should probably read: u32 value = get_unaligned((u32 *)data); /DM - To unsubscribe from this list: send the

Re: [RFC v2] Documentation about unaligned memory access

of myfunc. Since data is a u8* it will only get one byte of data. To avoid misunderstandings the code should probably read: u32 value = get_unaligned((u32 *)data); /DM - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo

Re: [RFC] Documentation about unaligned memory access

memcpy(data, value, sizeof(value)); > [...] > } I suppose you mean: memcpy(data, , sizeof(value)); /DM - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at htt

Re: [RFC] Documentation about unaligned memory access

)); [...] } I suppose you mean: memcpy(data, value, sizeof(value)); /DM - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: [PATCH] sched: avoid large irq-latencies in smp-balancing

; next: > - if (!p) > + if (!p || loops++ > sysctl_sched_nr_migrate) > goto out; Looks to me like an off-by-one thingy. If sysctl_sched_nr_migrate is zero we can still migrate one task. Feature or bug? /dm - To unsubscribe from this list: send the line "unsub

Re: [PATCH] sched: avoid large irq-latencies in smp-balancing

++ sysctl_sched_nr_migrate) goto out; Looks to me like an off-by-one thingy. If sysctl_sched_nr_migrate is zero we can still migrate one task. Feature or bug? /dm - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More