Re: [PATCH] mm: More __meminit annotations.
Hi,
On 6/18/07, Yasunori Goto <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 18, 2007 at 02:49:24PM +0900, Yasunori Goto wrote:
> > > -static inline unsigned long zone_absent_pages_in_node(int nid,
> > > +static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
> > > unsigned long zone_type,
> > > unsigned long *zholes_size)
> > > {
> >
> > I thought __meminit is not effective for these static functions,
> > because they are inlined function. So, it depends on caller's
> > defenition. Is it wrong?
> >
> Ah, that's possible, I hadn't considered that. It seems to be a bit more
> obvious what the intention is if it's annotated, especially as this is
> the convention that's used by the rest of mm/page_alloc.c. A bit more
> consistent, if nothing more.
I'm not sure which is intended. I found some functions define both
__init and inline in kernel tree. And probably, some functions don't
do it. So, it seems there is no convention.
I'm Okay if you prefer both defined. :-)
Marking inline functions as __init (or __meminit etc) is quite insane,
IMHO. Note that all callers of the said inline function will also have to
be __init anyway (else modpost will barf) so the said function will
have all callsites in .init.text anyway, and hence would be inlined
in the same section as the caller (i.e. .init.text). [Note that kernel
uses always_inline.]
The annotation may still be a readability aid (which is subjective so
one can't really comment upon), but asking gcc to put into a separate
specified section, a function whose body would not be emitted by gcc
separately at all, doesn't really make much sense syntactically _or_
semantically -- gcc might not warn, of course, perhaps it's one of those
little things it takes care of by itself silently without complaining (like
taking pointers to inline functions).
Satyam
-
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: [BUG] long freezes on thinkpad t60
* Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > could you try the quick hack below, ontop of cfs-v17? It adds two > > things to wait_task_inactive(): > > > > - a cond_resched() [in case you are running !PREEMPT] > > > > - use MONITOR+MWAIT to monitor memory transactions to the rq->curr > > cacheline. This should make the polling loop definitely fair. > > Is it not possible for the mwait to get stuck? it is - when the other CPU does nothing. > > If this solves the problem on your box then i'll do a proper fix and > > introduce a cpu_relax_memory_change(*addr) type of API to around > > monitor/mwait. This patch boots fine on my T60 - but i never saw > > your problem. > > Yes, the patch does make the pauses go away. In fact just the > smp_mb() seems to suffice. cool! Could you send me the smallest patch you tried that still made the hangs go away? Ingo - 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] cdrom_sysctl_info fix
On Mon, Jun 18 2007, dave young wrote: > Hi, > >Yep that looks much better! I trust you booted and tested this and the > >output looks correct? > Yes, I tested and the output is correct. Good > BTW, another problem, I can't find the CONFIG_CDROM option in kernel > config menu. Is it deperacated? If it is true, is the module part > still necessary? cdrom.o is a hardware independent helper module, it gets included if you use atapi/scsi/etc cdrom drivers. See drivers/cdrom/Makefile. -- Jens Axboe - 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: [Suspend-devel] [PATCH, 3rd try] make disable_console_suspend runtime configurable
On Sun, Jun 17, 2007 at 11:49:40PM +0200, Pavel Machek wrote: > Hi! > > > > > I hate having to recompile the kernel, just to be able to debug suspend. > > > > Remove CONFIG_DISABLE_CONSOLE_SUSPEND, replace it by a tunable in > > > > /sys/power/disable_console_suspend. > > > > > > > > > > > > Signed-off-by: Stefan Seyfried <[EMAIL PROTECTED]> > > > > Signed-off-by: Frank Seidel <[EMAIL PROTECTED]> > > > > --- > > > > Third try, renamed sysfs interface to console_suspend > > > > reporting and expecting either "enabled" or "disabled" > > > > > > Thanks a lot for redoing it. > > > > > > I have no objections. Pavel? > > > > I still think that patch is bad. I should have screamed when > > CONFIG_DISABLE_CONSOLE_SUSPEND went into kernel. That beast should > > _not_ be configurable, it should just do the right thing. > > > > But I realized that too late. And this only makes it works, making > > that mistake part of user-kernel interface. > > > > Sorry for not screaming when CONFIG_DISABLE_CONSOLE_SUSPEND went in, > > but please lets solve this correctly > > Ouch and sorry for not screaming at "try 1" time. But it still does > not make the patch right, and I believe that even patch authors agree > that "no-config-needed" is superior solution. No, i don't agree at all. In this case, "no config needed" == "not possible to debug suspend problems". IMO this is the same as issue as with "sysrq-C". You can crash the machine by other means, but it sometimes is just handy to have a mechanism to do it. I do not understand what's the problem with this option. If you want to avoid that people use it for something else than debugging, i can add a patch that crashes the machine ten seconds after resume if this option is set. -- Stefan Seyfried QA / R&D Team Mobile Devices| "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - 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] cdrom_sysctl_info fix
Hi, Yep that looks much better! I trust you booted and tested this and the output looks correct? Yes, I tested and the output is correct. BTW, another problem, I can't find the CONFIG_CDROM option in kernel config menu. Is it deperacated? If it is true, is the module part still necessary? Regards dave - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, Jun 17, 2007 at 07:45:38PM -0500, Chris Adams wrote: > Once upon a time, Bron Gondwana <[EMAIL PROTECTED]> said: > > To be fair here, this could also be accomplished by having to flip a > > physical switch on the router, especially if you did something funky > > like: > > > > [---] push this button for a 5 minute access pass to upload new > > software through physical cable port 1. > > > > More complex, but not unreasonable. > > Well, there is no restriction on putting files on the routing engine's > storage devices (flash and hard drive); it is running OpenSSH, so > scp/sftp work fine, and you can drop to a shell easily. The restriction > is that the kernel won't run unsigned binaries. > > Also, flipping physical switches is pretty much an unreasonable > expectation for core router operation. These are often in other > locations, sometimes other telcos' central offices (where you have to > pay to have "remote hands" do something and then hope they don't screw > it up). You can easily go the entire life of a device where the primary > operators never physically see the device. Every server I run is like that, but if something is important enough I can remote control a robot over to push the button for me (actually, I think they implement this under the hood by having a human read the ticket I submit and go push the button for me manually, but that could be my imagination. So long as the button gets pushed the black box is functioning) Bron. - 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] mm: More __meminit annotations.
> On Mon, Jun 18, 2007 at 02:49:24PM +0900, Yasunori Goto wrote:
> > > -static inline unsigned long zone_absent_pages_in_node(int nid,
> > > +static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
> > > unsigned long zone_type,
> > > unsigned long *zholes_size)
> > > {
> >
> > I thought __meminit is not effective for these static functions,
> > because they are inlined function. So, it depends on caller's
> > defenition. Is it wrong?
> >
> Ah, that's possible, I hadn't considered that. It seems to be a bit more
> obvious what the intention is if it's annotated, especially as this is
> the convention that's used by the rest of mm/page_alloc.c. A bit more
> consistent, if nothing more.
I'm not sure which is intended. I found some functions define both
__init and inline in kernel tree. And probably, some functions don't
do it. So, it seems there is no convention.
I'm Okay if you prefer both defined. :-)
--
Yasunori Goto
-
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] make hdrscheck.sh force __asm__ in exported headers
On 6/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Monday 18 June 2007, Andrew Morton wrote: > > And does the kernel pass these checks? > > nope ... should i audit the arches before this gets merged ? Yes please. I'd rather not break things in this fashion: it causes a storm of emails which I need to redirect to the appropriate maintainers who then take an arbitrarily long time to do anything. Meanwhile lots of testers get impacted and this reduces the testing level of all the other thousands of patches in there. with the few patches i just sent out, the following pass: alpha arm avr32 blackfin i386 ia64 m68k mips powerpc s390 sh sparc x86_64 cris and parisc fail vanilla git regardless -mike - 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] cdrom_sysctl_info fix
On Mon, Jun 18 2007, Dave Young wrote: > I rewite the patch according to yours, please help to check. Pass the > cdrom_print_info function one more argument for diffrent type > printing, do you have better solutions for this? thanks for replying > :) Yep that looks much better! I trust you booted and tested this and the output looks correct? -- Jens Axboe - 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: [2.6 patch] include/linux/kprobes.h: always offer show_registers() prototype
On Mon, Jun 18, 2007 at 01:43:04AM +0200, Adrian Bunk wrote:
> Allow gcc to perform show_registers() type checking also with
> CONFIG_KPROBES=n.
>
Adrian,
Please implement it as Andrew suggested, when this was patch was posted
eariler. Refer this discussion thread below.
http://lkml.org/lkml/2007/4/27/576
NACK
Thanks
Prasanna
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> This patch has been sent on:
> - 27 Apr 2007
> - 27 Mar 2007
>
> include/linux/kprobes.h |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> --- linux-2.6.21-rc4-mm1/include/linux/kprobes.h.old 2007-03-26
> 15:28:27.0 +0200
> +++ linux-2.6.21-rc4-mm1/include/linux/kprobes.h 2007-03-26
> 15:32:23.0 +0200
> @@ -163,7 +163,6 @@
> extern void arch_arm_kprobe(struct kprobe *p);
> extern void arch_disarm_kprobe(struct kprobe *p);
> extern int arch_init_kprobes(void);
> -extern void show_registers(struct pt_regs *regs);
> extern kprobe_opcode_t *get_insn_slot(void);
> extern void free_insn_slot(kprobe_opcode_t *slot, int dirty);
> extern void kprobes_inc_nmissed_count(struct kprobe *p);
> @@ -241,4 +240,7 @@
> {
> }
> #endif /* CONFIG_KPROBES */
> +
> +void show_registers(struct pt_regs *regs);
> +
> #endif /* _LINUX_KPROBES_H */
--
Prasanna S.P.
Linux Technology Center
India Software Labs, IBM Bangalore
Email: [EMAIL PROTECTED]
Ph: 91-80-41776329
-
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/
[patch] use __asm__ rather than asm in asm-s390/ptrace.h
Since asm-s390/ptrace.h is exported to userspace, we need to make sure we use
__asm__() rather than asm() as the latter is disabled when gcc compiles with
GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-s390/ptrace.h b/include/asm-s390/ptrace.h
index fa6ca87..4add355 100644
--- a/include/asm-s390/ptrace.h
+++ b/include/asm-s390/ptrace.h
@@ -475,7 +475,7 @@ extern void show_regs(struct pt_regs * regs);
static inline void
psw_set_key(unsigned int key)
{
- asm volatile("spka 0(%0)" : : "d" (key));
+ __asm__ __volatile__("spka 0(%0)" : : "d" (key));
}
#endif /* __ASSEMBLY__ */
-
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/
[patch] use __asm__ and __volatile__ in asm-ia64/gcc_intrin.h
Since asm-ia64/gcc_intrin.h gets exported to userspace, we need to make sure
to use __asm__() rather than asm() since the latter is not available when
compiling with gcc with GNU extensions turned off (like -std=c99).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-ia64/gcc_intrin.h b/include/asm-ia64/gcc_intrin.h
index 4fb4e43..0bb24df 100644
--- a/include/asm-ia64/gcc_intrin.h
+++ b/include/asm-ia64/gcc_intrin.h
@@ -13,41 +13,41 @@
/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
-#define ia64_barrier() asm volatile ("":::"memory")
+#define ia64_barrier() __asm__ __volatile__ ("":::"memory")
-#define ia64_stop()asm volatile (";;"::)
+#define ia64_stop()__asm__ __volatile__ (";;"::)
-#define ia64_invala_gr(regnum) asm volatile ("invala.e r%0" :: "i"(regnum))
+#define ia64_invala_gr(regnum) __asm__ __volatile__ ("invala.e r%0" ::
"i"(regnum))
-#define ia64_invala_fr(regnum) asm volatile ("invala.e f%0" :: "i"(regnum))
+#define ia64_invala_fr(regnum) __asm__ __volatile__ ("invala.e f%0" ::
"i"(regnum))
extern void ia64_bad_param_for_setreg (void);
extern void ia64_bad_param_for_getreg (void);
-register unsigned long ia64_r13 asm ("r13") __attribute_used__;
+register unsigned long ia64_r13 __asm__ ("r13") __attribute_used__;
#define ia64_setreg(regnum, val)
\
({
\
switch (regnum) {
\
case _IA64_REG_PSR_L:
\
- asm volatile ("mov psr.l=%0" :: "r"(val) : "memory");
\
+ __asm__ __volatile__ ("mov psr.l=%0" :: "r"(val) :
"memory"); \
break;
\
case _IA64_REG_AR_KR0 ... _IA64_REG_AR_EC:
\
- asm volatile ("mov ar%0=%1" ::
\
+ __asm__ __volatile__ ("mov ar%0=%1" ::
\
"i" (regnum - _IA64_REG_AR_KR0),
\
"r"(val): "memory");
\
break;
\
case _IA64_REG_CR_DCR ... _IA64_REG_CR_LRR1:
\
- asm volatile ("mov cr%0=%1" ::
\
+ __asm__ __volatile__ ("mov cr%0=%1" ::
\
"i" (regnum - _IA64_REG_CR_DCR),
\
"r"(val): "memory" );
\
break;
\
case _IA64_REG_SP:
\
- asm volatile ("mov r12=%0" ::
\
+ __asm__ __volatile__ ("mov r12=%0" ::
\
"r"(val): "memory");
\
break;
\
case _IA64_REG_GP:
\
- asm volatile ("mov gp=%0" :: "r"(val) : "memory");
\
+ __asm__ __volatile__ ("mov gp=%0" :: "r"(val) : "memory");
\
break;
\
default:
\
ia64_bad_param_for_setreg();
\
@@ -61,27 +61,27 @@ register unsigned long ia64_r13 asm ("r13")
__attribute_used__;
\
switch (regnum) {
\
case _IA64_REG_GP:
\
- asm volatile ("mov %0=gp" : "=r"(ia64_intri_res));
\
+ __asm__ __volatile__ ("mov %0=gp" : "=r"(ia64_intri_res));
\
break;
\
case _IA64_REG_IP:
\
- asm volatile ("mov %0=ip" : "=r"(ia64_intri_res));
\
+ __asm__ __volatile__ ("mov %0=ip" : "=r"(ia64_intri_res));
\
break;
\
case _IA64_REG_PSR:
\
- asm volatile ("mov %0=psr" : "=r"(ia64_intri_res));
\
+ __asm__ __volatile__ ("mov %0=psr"
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, 2007-06-17 at 19:14 +0200, Gabor Czigola wrote: > Hello! > > I didn't follow the whole thread from the beginning, but I see that > there are pros and cons for both versions of GPL. > > I wonder why the linux kernel development community couldn't propose > an own GPL draft (say v2.2) that is "as free as v2" and that includes > some ideas (from v3) that are considered as good (free, innovative, in > the spirit of whatever etc.) by the majority of the kernel developers. > > I guess to have an own version of the GPL license could also help to > resolve (future) dual-licensing problems. > > Gabor Czigola They very well could. There are provisions (I had to dig through gnu.org) to find them, but you are perfecly O.K. to take the legal terms of the GPL and make them your own in your own license. You can't copy their preamble without permission, and it can have no mention of GNU in the license once you finish. The issue would be compatibility. You can't have licenses fighting each other in your project, undesirable effects could include not being able to merge with code that remains under the original license. The popularity of GPL2 would make this rather impractical, but if this is no issue to you then there is no problem. In a kernel, its a big problem. Best, --Tim - 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/
[patch] use __asm__ and __volatile__ in asm-x86_64/msr.h
Most of the macros in msr.h already use __asm__ and __volatile__, this patch
brings the rest into line. This is needed since these get exported into
userspace (need to use strict __asm__ vs asm when gcc compiles with GNU
extensions turned off).
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-x86_64/msr.h b/include/asm-x86_64/msr.h
index d5c55b8..ed15d2b 100644
--- a/include/asm-x86_64/msr.h
+++ b/include/asm-x86_64/msr.h
@@ -33,7 +33,7 @@
/* wrmsr with exception handling */
#define wrmsr_safe(msr,a,b) ({ int ret__; \
- asm volatile("2: wrmsr ; xorl %0,%0\n" \
+ __asm__ __volatile__("2: wrmsr ; xorl %0,%0\n" \
"1:\n\t" \
".section .fixup,\"ax\"\n\t" \
"3: movl %4,%0 ; jmp 1b\n\t" \
@@ -50,7 +50,7 @@
#define rdmsr_safe(msr,a,b) \
({ int ret__; \
- asm volatile ("1: rdmsr\n" \
+ __asm__ __volatile__ ("1: rdmsr\n" \
"2:\n" \
".section .fixup,\"ax\"\n" \
"3: movl %4,%0\n" \
@@ -70,17 +70,17 @@
__asm__ __volatile__ ("rdtsc" : "=a" (low) : : "edx")
#define rdtscp(low,high,aux) \
- asm volatile (".byte 0x0f,0x01,0xf9" : "=a" (low), "=d" (high), "=c"
(aux))
+ __asm__ __volatile__ (".byte 0x0f,0x01,0xf9" : "=a" (low), "=d" (high),
"=c" (aux))
#define rdtscll(val) do { \
unsigned int __a,__d; \
- asm volatile("rdtsc" : "=a" (__a), "=d" (__d)); \
+ __asm__ __volatile__("rdtsc" : "=a" (__a), "=d" (__d)); \
(val) = ((unsigned long)__a) | (((unsigned long)__d)<<32); \
} while(0)
#define rdtscpll(val, aux) do { \
unsigned long __a, __d; \
- asm volatile (".byte 0x0f,0x01,0xf9" : "=a" (__a), "=d" (__d), "=c"
(aux)); \
+ __asm__ __volatile__ (".byte 0x0f,0x01,0xf9" : "=a" (__a), "=d" (__d),
"=c" (aux)); \
(val) = (__d << 32) | __a; \
} while (0)
-
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: [BUG] libata IT821X driver still fails! Hard-freezes system.
Rodney Gordon II wrote: > This is the screen image I took with my digital camera when bootup > freezes: > http://spherevision.org/sync/visual/itefreeze.jpg > > After this freeze, not even SysRq commands work. > On a side-note, the non-libata drivers boot up, but throw tons of DMA > errors after one DVD burn. > > The kernel I tested this on (newest I would try) is 2.6.22-rc4 with and > without cfs16. I am willing to test out patches if I can get this darn > controller working. Does ide it821x driver work? (drivers -> ata/atapi/mfm/rll support -> it821x ide support) -- tejun - 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/
[patch] hide cond_syscall behind __KERNEL__ for Blackfin/x86_64
This brings Blackfin and x86_64 into line with all other architectures by only
defining cond_syscall() when __KERNEL__ is defined.
Signed-off-by: Mike Frysinger <[EMAIL PROTECTED]>
---
diff --git a/include/asm-blackfin/unistd.h b/include/asm-blackfin/unistd.h
index 4df8790..0df9f2d 100644
--- a/include/asm-blackfin/unistd.h
+++ b/include/asm-blackfin/unistd.h
@@ -369,7 +369,6 @@
#define __ARCH_WANT_SYS_NICE
#define __ARCH_WANT_SYS_RT_SIGACTION
#define __ARCH_WANT_SYS_RT_SIGSUSPEND
-#endif
/*
* "Conditional" syscalls
@@ -379,4 +378,6 @@
*/
#define cond_syscall(x) asm(".weak\t_" #x "\n\t.set\t_" #x ",_sys_ni_syscall");
+#endif /* __KERNEL__ */
+
#endif /* __ASM_BFIN_UNISTD_H */
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index ae1ed05..f5d627c 100644
--- a/include/asm-x86_64/unistd.h
+++ b/include/asm-x86_64/unistd.h
@@ -674,6 +674,7 @@ asmlinkage long sys_rt_sigaction(int sig,
#endif /* __KERNEL__ */
#endif /* __NO_STUBS */
+#ifdef __KERNEL__
/*
* "Conditional" syscalls
*
@@ -681,5 +682,6 @@ asmlinkage long sys_rt_sigaction(int sig,
* but it doesn't work on all toolchains, so we just do it by hand
*/
#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
+#endif /* __KERNEL__ */
#endif /* _ASM_X86_64_UNISTD_H_ */
-
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] mm: More __meminit annotations.
On Mon, Jun 18, 2007 at 02:49:24PM +0900, Yasunori Goto wrote:
> > -static inline unsigned long zone_absent_pages_in_node(int nid,
> > +static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
> > unsigned long zone_type,
> > unsigned long *zholes_size)
> > {
>
> I thought __meminit is not effective for these static functions,
> because they are inlined function. So, it depends on caller's
> defenition. Is it wrong?
>
Ah, that's possible, I hadn't considered that. It seems to be a bit more
obvious what the intention is if it's annotated, especially as this is
the convention that's used by the rest of mm/page_alloc.c. A bit more
consistent, if nothing more.
-
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: [2.6 patch] fix devres_release_all() return value
Adrian Bunk wrote: > Every file should include the headers containing the prototypes for > it's global functions. > > Since the GNU C compiler is now able to detect that the function > prototype of devres_release_all() in the header and the actual function > disagree regarding the return value, this patch also fixes this bug. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> This should go through Greg. http://article.gmane.org/gmane.linux.kernel/544290/raw -- tejun - 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] make hdrscheck.sh force __asm__ in exported headers
On Monday 18 June 2007, Andrew Morton wrote: > Also, your changelog sucks: > > This updates scripts/hdrschecks.sh by grepping for asm() constructs and > rejecting them in favor of __asm__() in exported headers. > > well OK. But for what reason? We can see a lot of pain in this patch but > no gain. The changelog should tell us what the benefit is, so we can make > informed tradeoff decisions. err, should have included the rationale in previous e-mail ... we want to audit asm/volatile because both constructs will fail in userland builds when GNU extensions are turned off (like -std=c99) ... __asm__ and __volatile__ will work in both places. -mike signature.asc Description: This is a digitally signed message part.
Re: [patch] make hdrscheck.sh force __asm__ in exported headers
On Monday 18 June 2007, Andrew Morton wrote: > On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Monday 18 June 2007, Andrew Morton wrote: > > > On 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > > This updates scripts/hdrschecks.sh by grepping for asm() constructs > > > > and rejecting them in favor of __asm__() in exported headers. > > > > > > And does the kernel pass these checks? > > > > nope ... should i audit the arches before this gets merged ? > > Yes please. I'd rather not break things in this fashion: it causes a storm > of emails which I need to redirect to the appropriate maintainers who then > take an arbitrarily long time to do anything. Meanwhile lots of testers > get impacted and this reduces the testing level of all the other thousands > of patches in there. makes sense, i'll post some stuff > Also, your changelog sucks: > > This updates scripts/hdrschecks.sh by grepping for asm() constructs and > rejecting them in favor of __asm__() in exported headers. > > well OK. But for what reason? We can see a lot of pain in this patch but > no gain. The changelog should tell us what the benefit is, so we can make > informed tradeoff decisions. sorry, i blame GNU changelog style ;) -mike signature.asc Description: This is a digitally signed message part.
Re: [PATCH] mm: More __meminit annotations.
Thanks for your checking.
> -void zone_init_free_lists(struct pglist_data *pgdat, struct zone *zone,
> - unsigned long size)
> +static void __meminit zone_init_free_lists(struct pglist_data *pgdat,
> + struct zone *zone, unsigned long size)
> {
> int order;
> for (order = 0; order < MAX_ORDER ; order++) {
> @@ -2431,7 +2431,7 @@ void __meminit get_pfn_range_for_nid(unsigned int nid,
> * Return the number of pages a zone spans in a node, including holes
> * present_pages = zone_spanned_pages_in_node() - zone_absent_pages_in_node()
> */
> -unsigned long __meminit zone_spanned_pages_in_node(int nid,
> +static unsigned long __meminit zone_spanned_pages_in_node(int nid,
> unsigned long zone_type,
> unsigned long *ignored)
> {
> @@ -2519,7 +2519,7 @@ unsigned long __init absent_pages_in_range(unsigned
> long start_pfn,
> }
>
> /* Return the number of page frames in holes in a zone on a node */
> -unsigned long __meminit zone_absent_pages_in_node(int nid,
> +static unsigned long __meminit zone_absent_pages_in_node(int nid,
> unsigned long zone_type,
> unsigned long *ignored)
> {
Ah, Yes. Thanks. It is better.
> @@ -2536,14 +2536,14 @@ unsigned long __meminit zone_absent_pages_in_node(int
> nid,
> }
>
> #else
> -static inline unsigned long zone_spanned_pages_in_node(int nid,
> +static inline unsigned long __meminit zone_spanned_pages_in_node(int nid,
> unsigned long zone_type,
> unsigned long *zones_size)
> {
> return zones_size[zone_type];
> }
>
> -static inline unsigned long zone_absent_pages_in_node(int nid,
> +static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
> unsigned long zone_type,
> unsigned long *zholes_size)
> {
I thought __meminit is not effective for these static functions,
because they are inlined function. So, it depends on caller's
defenition. Is it wrong?
Bye.
--
Yasunori Goto
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Mon, 2007-06-18 at 01:08 +0300, Al Boldi wrote: > Alexandre Oliva wrote: > > On Jun 17, 2007, Al Boldi <[EMAIL PROTECTED]> wrote: > > > Under what circumstances would it be possible to receive permission for > > > modification? > > > > You have to ask the copyright holder. > > > > Affero did just that, and so the Affero GPL was born. > > > > Just don't assume the FSF will grant such permissions lightly. > > But wouldn't this be against the spirit of the GPL? This may be helpful to you : http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL It describes the scenario and how to go about doing it. Best, --Tim - 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] make hdrscheck.sh force __asm__ in exported headers
On Mon, 18 Jun 2007 01:17:46 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Monday 18 June 2007, Andrew Morton wrote: > > On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > This updates scripts/hdrschecks.sh by grepping for asm() constructs and > > > rejecting them in favor of __asm__() in exported headers. > > > > And does the kernel pass these checks? > > nope ... should i audit the arches before this gets merged ? Yes please. I'd rather not break things in this fashion: it causes a storm of emails which I need to redirect to the appropriate maintainers who then take an arbitrarily long time to do anything. Meanwhile lots of testers get impacted and this reduces the testing level of all the other thousands of patches in there. > > Which architectures have been tested? > > i386 passes, blackfin/x86_64 fail a simple asm/unistd.h, and x86_64 fails a > bunch in asm/msr.h, but last time i tried to patch that, the maintainer said > they were going to be hiding a bunch of that stuff anyways Well I would prefer that we merge as many fixes as poss into -mm before merging this patch - to reduce the impact on testers. If these fixes are "wrong" but work then that's fine. I just keep spamming the maintainer with the wrong-but-works patch until he wakes up and fixes it for real. Also, your changelog sucks: This updates scripts/hdrschecks.sh by grepping for asm() constructs and rejecting them in favor of __asm__() in exported headers. well OK. But for what reason? We can see a lot of pain in this patch but no gain. The changelog should tell us what the benefit is, so we can make informed tradeoff decisions. - 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: spurious completions during NCQ?
Massimiliano Hofer wrote: > On Friday 8 June 2007, Alan Cox wrote: > >>> Model Number: HITACHI HTS541680J9SA00 >>> Serial Number: SB**I57L4A >> This one is already blacklisted in the windows drivers. > > I have the same problem with this drive (shipped with a Thinkpad Z61m): > > Model Number: HITACHI HTS541612J9SA00 > Firmware Revision: SBDIC7JP > > It reported several dozen spurious completions over a few days, but I can't > find any corruption. Is it really dangerous? I understand this clearly is a > firmware bug, but I'm not sure how to interpret the drive behavior. > I can perform any test you like, if you find it useful. It has _slight_ change of being dangerous and is just in violation of the protocol. No real data corruption case reported yet tho. Till now most drives which report such problems had stinky NCQ implementation anyway - slow, buggy, blacklisted in the other OS, etc... I'll submit a patch to blacklist the drive. Thanks. -- tejun - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, 2007-06-17 at 14:13 -0700, [EMAIL PROTECTED] wrote: > you argue that it is evil for tivo to produce a pice of hardware that they > can modify and the user can't > > but you then argue that it's a good thing for the FSF to produce a license > that they can modify and others can't They can't modify the license that you used. They can make a new license which you may optionally use at your discretion. Once you release the code under the GPL(x), that is it. The only person who can change that is you or perhaps some bizarre court order. But it would still be you changing it, even if your hand was forced to do so. Your copyright is your signing mechanism. Once you do it, its a done deed. That is the whole reason Linus chose GPL2 to begin with, I believe :) You and _only_ you are the one. Its like a biometric lock. Best, --Tim - 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] make hdrscheck.sh force __asm__ in exported headers
On Monday 18 June 2007, Andrew Morton wrote: > On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > > This updates scripts/hdrschecks.sh by grepping for asm() constructs and > > rejecting them in favor of __asm__() in exported headers. > > And does the kernel pass these checks? nope ... should i audit the arches before this gets merged ? > Which architectures have been tested? i386 passes, blackfin/x86_64 fail a simple asm/unistd.h, and x86_64 fails a bunch in asm/msr.h, but last time i tried to patch that, the maintainer said they were going to be hiding a bunch of that stuff anyways -mike signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, 2007-06-17 at 23:19 +0300, Al Boldi wrote: > > Wow! > > Under what circumstances would it be possible to receive permission for > modification? > > > Thanks for being GPL! > > -- > Al > If the GPL2 were itself modifiable, there would be so many GPL licenses that the term "Relased under the GPL 2" would only indicate you chose one of a million licenses or wrote your own. That may not be a bad thing, not for me to debate. But I think that's why the FSF imposes the restriction. I don't feel that is unreasonable, but you might, and its your right to do so and be vocal about it. You could, of course take what language that you agree with, re-write it and make it your own and add a clause that allows people to modify the license provided that they do not call it the "XYZ" license any longer. But you wouldn't be making a license - you'd be making the raw material for people to make their own license. I don't think that's what the FSF wanted to accomplish. Again, just my opinion. I didn't make the GPL so there's no way I could know. Best, --Tim - 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] make hdrscheck.sh force __asm__ in exported headers
On Sun, 17 Jun 2007 18:54:24 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: > This updates scripts/hdrschecks.sh by grepping for asm() constructs and > rejecting them in favor of __asm__() in exported headers. And does the kernel pass these checks? Which architectures have been tested? - 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: How to improve the quality of the kernel?
On Mon, 18 Jun 2007 01:15:15 +0200 Stefan Richter <[EMAIL PROTECTED]> wrote: > Tested-by Tested-by would be good too. Because over time, we will generate a list of people who own the relevant hardware and who are prepared to test changes. So if you make changes to random-driver.c you can do `git-log random-driver.c|grep Tested-by" to find people who can test your changes for you. Not that many people are likely to bother. The consequences of being slack are negligible, hence there is little incentive to do the extra work. - 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: limits on raid
On Sat, Jun 16, 2007 at 07:59:29AM +1000, Neil Brown wrote: > Combining these thoughts, it would make a lot of sense for the > filesystem to be able to say to the block device "That blocks looks > wrong - can you find me another copy to try?". That is an example of > the sort of closer integration between filesystem and RAID that would > make sense. I think that this would only be useful on devices that store discrete copies of the blocks on different devices i.e. mirrors. If it's an XOR based RAID, you don't have another copy you can retreive Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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/
[PATCH] relay-file-read-start-pos-fix.patch
-- David Wilder IBM Linux Technology Center Beaverton, Oregon, USA [EMAIL PROTECTED] (503)578-3789 This patch fixes a bug in the relay read interface causing the number of consumed bytes to be set incorrectly. Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]> Signed-off-by: David Wilder <[EMAIL PROTECTED]> kernel/relay.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/relay.c b/kernel/relay.c index 4311101..e61156e 100644 --- a/kernel/relay.c +++ b/kernel/relay.c @@ -899,7 +899,10 @@ static size_t relay_file_read_start_pos(size_t read_pos, size_t read_subbuf, padding, padding_start, padding_end; size_t subbuf_size = buf->chan->subbuf_size; size_t n_subbufs = buf->chan->n_subbufs; + size_t consumed = buf->subbufs_consumed % n_subbufs; + if (!read_pos) + read_pos = consumed * subbuf_size + buf->bytes_consumed; read_subbuf = read_pos / subbuf_size; padding = buf->padding[read_subbuf]; padding_start = (read_subbuf + 1) * subbuf_size - padding;
[RFC] Generic Trace Setup and Control (GTSC) kernel API (2/3)
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
[EMAIL PROTECTED]
(503)578-3789
This patch introduces the Generic Trace Setup and Control (GTSC) API.
In the kernel, GTSC provides a simple API for starting and managing
data channels to user space. GTSC builds on the relay interface.
The documentation for the GTSC is provided in a separate patch.
Signed-off-by: David Wilder <[EMAIL PROTECTED]>
include/linux/gtsc.h | 124
lib/Kconfig |9 ++
lib/Makefile |2 +
lib/gtsc.c | 385 ++
4 files changed, 520 insertions(+), 0 deletions(-)
diff --git a/include/linux/gtsc.h b/include/linux/gtsc.h
new file mode 100644
index 000..224aa16
--- /dev/null
+++ b/include/linux/gtsc.h
@@ -0,0 +1,124 @@
+/*
+ * gtsc.h - GTSC defines and function prototypes
+ *
+ * Copyright (C) 2006 IBM Inc.
+ *
+ * Tom Zanussi <[EMAIL PROTECTED]>
+ * Martin Hunt <[EMAIL PROTECTED]>
+ * David Wilder <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+#ifndef _LINUX_GTSC_H
+#define _LINUX_GTSC_H
+
+#include
+
+/*
+ * GTSC channel flags
+ */
+#define GTSC_GLOBAL 0x01
+#define GTSC_FLIGHT 0x02
+
+enum {
+ Gtsc_trace_setup = 1,
+ Gtsc_trace_running,
+ Gtsc_trace_stopped,
+};
+
+#define GTSC_TRACE_ROOT_NAME_SIZE 64 /* Max root dir identifier */
+#define GTSC_TRACE_NAME_SIZE 64 /* Max trace identifier */
+
+/*
+ * Global root user information
+ */
+struct gtsc_root {
+ struct list_head list;
+ char gtsc_name[GTSC_TRACE_ROOT_NAME_SIZE];
+ struct dentry *gtsc_root;
+ unsigned int gtsc_users;
+};
+
+/*
+ * Client information
+ */
+struct gtsc_trace {
+ int trace_state;
+ struct dentry *state_file;
+ struct rchan *rchan;
+ struct dentry *dir;
+ struct dentry *dropped_file;
+ atomic_t dropped;
+ struct gtsc_root *root;
+ void *private_data;
+ unsigned int flags;
+ unsigned int buf_size;
+ unsigned int buf_nr;
+};
+
+static inline int gtsc_trace_running(struct gtsc_trace *gtsc)
+{
+ return gtsc->trace_state == Gtsc_trace_running;
+}
+
+#if defined(CONFIG_GTSC)
+
+/**
+ * gtsc_trace_setup: create a new gtsc trace handle
+ *
+ * @root: The root directory name in the root of the debugfs
+ * to place trace directories. Created as needed.
+ * @name: Trace directory name, created in @root
+ * @buf_size: size of the relay sub-buffers
+ * @buf_nr: number of relay sub-buffers
+ * @flags: Option selection (see GTSC channel flags definitions)
+ * default values when flags=0 are: use per-CPU buffering,
+ * use non-overwrite mode. See Documentation/gtsc.txt for details.
+ *
+ * returns a gtsc_trace handle or NULL, if setup failed.
+ */
+extern struct gtsc_trace *gtsc_trace_setup(char *root, char *name, u32 buf_size,
+ u32 buf_nr, u32 flags);
+
+/**
+ * gtsc_trace_startstop: start or stop tracing.
+ *
+ * @gtsc: gtsc trace handle to start or stop.
+ * @start: set to 1 to start tracing set to 0 to stop.
+ *
+ * returns 0 if successful.
+ */
+extern int gtsc_trace_startstop(struct gtsc_trace *gtsc, int start);
+
+/**
+ * gtsc_trace_cleanup: destroys the gtsc channel.
+ *
+ * @gtsc: gtsc trace handle to cleanup
+ */
+extern void gtsc_trace_cleanup(struct gtsc_trace *gtsc);
+
+/**
+ * gtsc_timestamp: returns a time stamp.
+ */
+extern unsigned long long gtsc_timestamp(void);
+
+#else /* !CONFIG_GTSC */
+#define gtsc_trace_setup(root, name, buf_size, buf_nr, flags) (NULL)
+#define gtsc_trace_startstop(gtsc, start) (-EINVAL)
+#define gtsc_trace_cleanup(gtsc) do { } while (0)
+#define gtsc_timestamp(void) (unsigned long long) (0)
+#endif /* CONFIG_GTSC */
+
+#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index 2e7ae6b..d6e048f 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -124,4 +124,13 @@ config HAS_DMA
depends on !NO_DMA
default y
+config GTSC
+ bool "Generic Trace Setup and Control"
+ select RELAY
+ select DEBUG_FS
+ help
+ This option enables support for the GTSC.
+
+ If unsure, say N.
+
endmenu
diff --git a/lib/Makefile b/lib/Makefile
index c8c8e20..dcbdb5e 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -62,6 +62,8 @@ obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o
lib-$(CONFIG_GENERIC_BUG) += bug.o
+obj-$(CONFIG_GTSC) += gtsc.o
+
hostprogs-y := gen_crc32table
clean-files := crc32table.h
diff --git a/lib/gtsc.c b/lib/gtsc.c
new file mode 100644
index 000..c376006
--- /d
[RFC] Generic Trace Setup and Control (GTSC) kernel API (3/3)
Patches to convert blktrace to the new GTSC API.
Two patches are included, the first is to the kernel portion of
blktrace. Apply the second patch is to the blktrace user code.
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
[EMAIL PROTECTED]
(503)578-3789
This patch converts the blktrace facility to use the Generic Trace
Setup and Control (GTSC) API. (kernel patch)
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
Signed-off-by: David Wilder <[EMAIL PROTECTED]>
diff --git a/block/Kconfig b/block/Kconfig
index a50f481..9ae9a8c 100644
--- a/block/Kconfig
+++ b/block/Kconfig
@@ -30,7 +30,7 @@ config LBD
config BLK_DEV_IO_TRACE
bool "Support for tracing block io actions"
depends on SYSFS
- select RELAY
+ select GTSC
select DEBUG_FS
help
Say Y here, if you want to be able to trace the block layer actions
diff --git a/block/blktrace.c b/block/blktrace.c
index 3f0e7c3..b4acf89 100644
--- a/block/blktrace.c
+++ b/block/blktrace.c
@@ -36,7 +36,7 @@ static void trace_note(struct blk_trace *bt, pid_t pid, int action,
{
struct blk_io_trace *t;
- t = relay_reserve(bt->rchan, sizeof(*t) + len);
+ t = relay_reserve(bt->gtsc->rchan, sizeof(*t) + len);
if (t) {
const int cpu = smp_processor_id();
@@ -126,7 +126,7 @@ void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
pid_t pid;
int cpu;
- if (unlikely(bt->trace_state != Blktrace_running))
+ if (unlikely(!gtsc_trace_running(bt->gtsc)))
return;
what |= ddir_act[rw & WRITE];
@@ -152,7 +152,7 @@ void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
if (unlikely(tsk->btrace_seq != blktrace_seq))
trace_note_tsk(bt, tsk);
- t = relay_reserve(bt->rchan, sizeof(*t) + pdu_len);
+ t = relay_reserve(bt->gtsc->rchan, sizeof(*t) + pdu_len);
if (t) {
cpu = smp_processor_id();
sequence = per_cpu_ptr(bt->sequence, cpu);
@@ -178,55 +178,8 @@ void __blk_add_trace(struct blk_trace *bt, sector_t sector, int bytes,
EXPORT_SYMBOL_GPL(__blk_add_trace);
-static struct dentry *blk_tree_root;
-static struct mutex blk_tree_mutex;
-static unsigned int root_users;
-
-static inline void blk_remove_root(void)
-{
- if (blk_tree_root) {
- debugfs_remove(blk_tree_root);
- blk_tree_root = NULL;
- }
-}
-
-static void blk_remove_tree(struct dentry *dir)
-{
- mutex_lock(&blk_tree_mutex);
- debugfs_remove(dir);
- if (--root_users == 0)
- blk_remove_root();
- mutex_unlock(&blk_tree_mutex);
-}
-
-static struct dentry *blk_create_tree(const char *blk_name)
-{
- struct dentry *dir = NULL;
-
- mutex_lock(&blk_tree_mutex);
-
- if (!blk_tree_root) {
- blk_tree_root = debugfs_create_dir("block", NULL);
- if (!blk_tree_root)
- goto err;
- }
-
- dir = debugfs_create_dir(blk_name, blk_tree_root);
- if (dir)
- root_users++;
- else
- blk_remove_root();
-
-err:
- mutex_unlock(&blk_tree_mutex);
- return dir;
-}
-
static void blk_trace_cleanup(struct blk_trace *bt)
{
- relay_close(bt->rchan);
- debugfs_remove(bt->dropped_file);
- blk_remove_tree(bt->dir);
free_percpu(bt->sequence);
kfree(bt);
}
@@ -239,76 +192,14 @@ static int blk_trace_remove(request_queue_t *q)
if (!bt)
return -EINVAL;
- if (bt->trace_state == Blktrace_setup ||
- bt->trace_state == Blktrace_stopped)
+ if (!gtsc_trace_running(bt->gtsc)) {
+ gtsc_trace_cleanup(bt->gtsc);
blk_trace_cleanup(bt);
+ }
return 0;
}
-static int blk_dropped_open(struct inode *inode, struct file *filp)
-{
- filp->private_data = inode->i_private;
-
- return 0;
-}
-
-static ssize_t blk_dropped_read(struct file *filp, char __user *buffer,
-size_t count, loff_t *ppos)
-{
- struct blk_trace *bt = filp->private_data;
- char buf[16];
-
- snprintf(buf, sizeof(buf), "%u\n", atomic_read(&bt->dropped));
-
- return simple_read_from_buffer(buffer, count, ppos, buf, strlen(buf));
-}
-
-static const struct file_operations blk_dropped_fops = {
- .owner = THIS_MODULE,
- .open = blk_dropped_open,
- .read = blk_dropped_read,
-};
-
-/*
- * Keep track of how many times we encountered a full subbuffer, to aid
- * the user space app in telling how many lost events there were.
- */
-static int blk_subbuf_start_callback(struct rchan_buf *buf, void *subbuf,
- void *prev_subbuf, size_t prev_padding)
-{
- struct blk_trace *bt;
-
- if (!relay_buf_full(buf))
- return 1;
-
- bt = buf->chan->private_data;
- atomic_inc(&bt->dropped);
- return 0;
-}
-
-static int blk_remove_buf_file_callback(struct dentry *dentry)
-{
- debugfs_remove(dentry);
- return 0;
-}
-
-static struct dentry *blk_create_buf_file_callback(const char *filename,
- struct dentry *parent,
- int mode,
- struct rchan_buf *buf,
- int *is_global)
-{
- return debugfs_create_file(filename, mode, parent, buf,
- &relay_file_operations);
-}
-
-static struct rchan_callbacks blk_relay_callbacks = {
- .subbuf_start = blk_subbuf_start_callback,
- .create_buf_file = blk_create_buf_file_callback,
- .remove_buf_file = blk_remove_buf_file_callback,
-};
-
/*
* Setup eve
Re: [PATCH] cdrom_sysctl_info fix
Hi jens,
Thanks for rework this patch.But it has some bugs, results kernel oops.
On Fri, Jun 15, 2007 at 03:26:57PM +0200, Jens Axboe wrote:
> On Thu, Jun 14 2007, Dave Young wrote:
> > Hi,
> >
> > Fix the cdrom_sysctl_info possible buffer overwrite bug. Somd
> > codingstyle fixes are included as well.
>
> How about something like this? The current code is actually racy,
> because there's no protection against adding/removing a cdrom while it
> runs. This patch is largely based on yours, just abstracted the printing
> and looping into a function and bail when we run out of room (and print
> a message to that effect).
You are right
>
> If you could test it and verify that it does the right thing (eg prints
> the same as before), that would be great!
>
> diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
> index 3625a05..ae5a475 100644
> --- a/drivers/cdrom/cdrom.c
> +++ b/drivers/cdrom/cdrom.c
> @@ -302,7 +302,7 @@ module_param(lockdoor, bool, 0);
> module_param(check_media_type, bool, 0);
> module_param(mrw_format_restart, bool, 0);
>
> -static DEFINE_SPINLOCK(cdrom_lock);
> +static DEFINE_MUTEX(cdrom_mutex);
>
> static const char *mrw_format_status[] = {
> "not mrw",
> @@ -438,10 +438,10 @@ int register_cdrom(struct cdrom_device_info *cdi)
> cdo->generic_packet = cdrom_dummy_generic_packet;
>
> cdinfo(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
> - spin_lock(&cdrom_lock);
> + mutex_lock(&cdrom_mutex);
> cdi->next = topCdromPtr;
> topCdromPtr = cdi;
> - spin_unlock(&cdrom_lock);
> + mutex_unlock(&cdrom_mutex);
> return 0;
> }
> #undef ENSURE
> @@ -452,7 +452,7 @@ int unregister_cdrom(struct cdrom_device_info *unreg)
> cdinfo(CD_OPEN, "entering unregister_cdrom\n");
>
> prev = NULL;
> - spin_lock(&cdrom_lock);
> + mutex_lock(&cdrom_mutex);
> cdi = topCdromPtr;
> while (cdi && cdi != unreg) {
> prev = cdi;
> @@ -460,7 +460,7 @@ int unregister_cdrom(struct cdrom_device_info *unreg)
> }
>
> if (cdi == NULL) {
> - spin_unlock(&cdrom_lock);
> + mutex_unlock(&cdrom_mutex);
> return -2;
> }
> if (prev)
> @@ -468,7 +468,7 @@ int unregister_cdrom(struct cdrom_device_info *unreg)
> else
> topCdromPtr = cdi->next;
>
> - spin_unlock(&cdrom_lock);
> + mutex_unlock(&cdrom_mutex);
>
> if (cdi->exit)
> cdi->exit(cdi);
> @@ -3289,103 +3289,112 @@ static struct cdrom_sysctl_settings {
> int check; /* check media type */
> } cdrom_sysctl_settings;
>
> +static int cdrom_print_int(const char *header, int val, char *info, int *pos)
> +{
The val is diffrent for every devices, isn't it?
> + const int max_size = sizeof(cdrom_sysctl_settings.info);
> + struct cdrom_device_info *cdi;
> + int ret;
> +
> + ret = scnprintf(info + *pos, max_size, header);
> + if (!ret)
> + return 1;
> +
> + *pos += ret;
> +
> + for (cdi = topCdromPtr; cdi; cdi = cdi->next) {
> + ret = scnprintf(info + *pos, max_size, "\t%d", val);
The max_size should be max_size - *pos
> + if (!ret)
> + return 1;
> + *pos += ret;
> + }
> +
> + return 0;
> +}
> +
> static int cdrom_sysctl_info(ctl_table *ctl, int write, struct file * filp,
> void __user *buffer, size_t *lenp, loff_t *ppos)
> {
> -int pos;
> + int pos;
> struct cdrom_device_info *cdi;
> char *info = cdrom_sysctl_settings.info;
> + const int max_size = sizeof(cdrom_sysctl_settings.info);
>
> if (!*lenp || (*ppos && !write)) {
> *lenp = 0;
> return 0;
> }
>
> + mutex_lock(&cdrom_mutex);
> +
> pos = sprintf(info, "CD-ROM information, " VERSION "\n");
>
> - pos += sprintf(info+pos, "\ndrive name:\t");
> - for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
> - pos += sprintf(info+pos, "\t%s", cdi->name);
> -
> - pos += sprintf(info+pos, "\ndrive speed:\t");
> - for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
> - pos += sprintf(info+pos, "\t%d", cdi->speed);
> -
> - pos += sprintf(info+pos, "\ndrive # of slots:");
> - for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
> - pos += sprintf(info+pos, "\t%d", cdi->capacity);
> -
> - pos += sprintf(info+pos, "\nCan close tray:\t");
> - for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
> - pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_CLOSE_TRAY) != 0);
> -
> - pos += sprintf(info+pos, "\nCan open tray:\t");
> - for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
> - pos += sprintf(info+pos, "\t%d", CDROM_CAN(CDC_OPEN_TRAY) != 0);
> -
> - pos += sprintf(info+pos, "\nCan lock tray:\t");
> - for (cdi=topCdromPtr;cdi!=NULL;cdi=cdi->next)
> - pos += sprintf(info+pos, "\t%d", CD
[RFC] Generic Trace Setup and Control (GTSC) kernel API (1/3)
Generic Trace Setup and Control (GTSC) kernel API. This patch and the patches to follow create a kernel API that simplifies the use of the relay subsystem. Any "relay" based tracing application has a common set of operations that they must performed to setup and control its relay channel(s). Block trace is an example of such an application. The goal of GTSC is to simply abstract out this generic code from block trace and make it available for other services to use. Doing so we can reduce the code in block trace as well as build a common trace control interface. I am submitting 3 patches for review. The first is included in this email, 2 and 3 will follow in separate emails. 1/3 GTSC documentation patch. (gtsc-documentation.patch) 2/3 The GTSC code itself. (gtsc.patch) 3/3 Patches to convert blktrace to the new GTSC API. (convert-blktrace-to-gtsc.patch, blktrace-gtsc-user.patch) The documentation patch describes the API and includes a simple kernel module that demonstrates the GTSC. I will be sending one additional patch not directly related to the GTSC. This patch fixes a bug in the relay read interface. I mention it here only because to make the GTSC example work properly you will need to apply this patch. This patch is named relay-file-read-start-pos-fix.patch. -- David Wilder IBM Linux Technology Center Beaverton, Oregon, USA [EMAIL PROTECTED] (503)578-3789 This patch provides the documentation for the Generic Trace Setup and Control (GTSC) API. In the kernel, GTSC provides a simple API for starting and managing data channels to user space. GTSC builds on the relay interface. The GTSC itself is provided in a separate patch. Signed-off-by: David Wilder <[EMAIL PROTECTED]> Documentation/gtsc.txt | 239 1 files changed, 239 insertions(+), 0 deletions(-) diff --git a/Documentation/gtsc.txt b/Documentation/gtsc.txt new file mode 100644 index 000..5a3a1b5 --- /dev/null +++ b/Documentation/gtsc.txt @@ -0,0 +1,239 @@ +Generic Trace Setup and Control (GTSC) +== +In the kernel, GTSC provides a simple API for starting and managing +data channels to user space. GTSC builds on the relay interface. For a +complete description of the relay interface, please see: +Documentation/filesystems/relay.txt. + +GTSC provides one layer in a complete tracing application. The idea of +the GTSC is to provide a kernel API for the setup and control of tracing +channels. User of GTSC must provide a data layer responsible for formatting +and writing data into the trace channels. + +A layered approach to tracing += +A complete kernel tracing application consists of a data provider and a data +consumer. Both provider and consumer contain three layers; each layer works +in tandem with the corresponding layer in the opposite side. The layers are +represented in the following diagram. + +Provider Data layer + Formats raw trace data and provides data-related service. + For example, adding timestamps used by consumer to sort data. + +Provider Control layer + Provided by GTSC. Creates trace channels and informs the data layer + and consumer of the current state of the trace channels. + +Provider Buffering layer + Provided by relay. This layer buffers data in the + kernel for consumption by the consumer's buffer + layer. + +Provider (in-kernel facility) +- +Consumer (user application) + + +Consumer Buffer layer + Reads/consumes data from the provider's data buffers. + +Consumer Control layer + Communicates to the provider's control layer to control the state + of the trace channels. + +Consumer Data layer + Sorts and formats data as provided by the provider's data layer. + +The provider is coded as a kernel facility. The consumer is coded as +a user application. + + +GTSC - Features +== +The GTSC exploits services and features provided by relay. These features are: +- The creation and destruction of relay channels. +- Buffer management. Overwrite or non-overwrite modes can be selected + as well as global or per-CPU buffering. + +Overwrite mode can be called "flight recorder mode". Flight recorder mode +is selected by setting the GTSC_FLIGHT flag when creating trace channels. +In flight mode when a tracing buffer is full, the oldest records in the buffer +will be discarded to make room as new records arrive. In the default +non-overwrite mode, new records may be written only if the buffer has room. +In either case, to prevent data loss, a user space reader must keep the buffers +drained. GTSC provides a means to detect the number of records that have been +dropped due to a buffer-full condition (non-overwrite mode only). + +When per-CPU buffers are used, relay creates one debugfs file for each running +CPU. The user-space consumer of the data is responsible for reading the +per-CPU buffe
[PATCH] mm: More __meminit annotations.
Currently zone_spanned_pages_in_node() and zone_absent_pages_in_node()
are non-static for ARCH_POPULATES_NODE_MAP and static otherwise. However,
only the non-static versions are __meminit annotated, despite only being
called from __meminit functions in either case.
zone_init_free_lists() is currently non-static and not __meminit
annotated either, despite only being called once in the entire tree by
init_currently_empty_zone(), which too is __meminit. So make it static
and properly annotated.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
mm/page_alloc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index bd8e335..12dc471 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1953,8 +1953,8 @@ void __meminit memmap_init_zone(unsigned long size, int
nid, unsigned long zone,
}
}
-void zone_init_free_lists(struct pglist_data *pgdat, struct zone *zone,
- unsigned long size)
+static void __meminit zone_init_free_lists(struct pglist_data *pgdat,
+ struct zone *zone, unsigned long size)
{
int order;
for (order = 0; order < MAX_ORDER ; order++) {
@@ -2431,7 +2431,7 @@ void __meminit get_pfn_range_for_nid(unsigned int nid,
* Return the number of pages a zone spans in a node, including holes
* present_pages = zone_spanned_pages_in_node() - zone_absent_pages_in_node()
*/
-unsigned long __meminit zone_spanned_pages_in_node(int nid,
+static unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
unsigned long *ignored)
{
@@ -2519,7 +2519,7 @@ unsigned long __init absent_pages_in_range(unsigned long
start_pfn,
}
/* Return the number of page frames in holes in a zone on a node */
-unsigned long __meminit zone_absent_pages_in_node(int nid,
+static unsigned long __meminit zone_absent_pages_in_node(int nid,
unsigned long zone_type,
unsigned long *ignored)
{
@@ -2536,14 +2536,14 @@ unsigned long __meminit zone_absent_pages_in_node(int
nid,
}
#else
-static inline unsigned long zone_spanned_pages_in_node(int nid,
+static inline unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
unsigned long *zones_size)
{
return zones_size[zone_type];
}
-static inline unsigned long zone_absent_pages_in_node(int nid,
+static inline unsigned long __meminit zone_absent_pages_in_node(int nid,
unsigned long zone_type,
unsigned long *zholes_size)
{
-
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: [-mm patch] arch/i386/video/fbdev.c should #include
On Mon, Jun 18, 2007 at 01:42:57AM +0200, Adrian Bunk wrote: > Every file should include the headers containing the prototypes for > it's global functions. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > --- > --- linux-2.6.22-rc4-mm2/arch/i386/video/fbdev.c.old 2007-06-17 > 15:48:25.0 +0200 > +++ linux-2.6.22-rc4-mm2/arch/i386/video/fbdev.c 2007-06-17 > 15:48:53.0 +0200 > @@ -11,6 +11,8 @@ > #include > #include > > +#include > + 1) Why not include asm/fb.h from linux/fb.h? 2) Is asm/fb.h an -mm thing? I do not have it in my linus tree. Note: Ketchup is broken on my ubuntu box so no -mm right now. Sam - 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 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Sun, 17 Jun 2007, Matt Mackall wrote: >> Is it? Last I looked it had reverted to handing out reverse-contiguous >> pages. On Sun, Jun 17, 2007 at 07:08:41PM -0700, Christoph Lameter wrote: > I thought that was fixed? Bill Irwin was working on it. > But the contiguous pages usually only work shortly after boot. After > awhile memory gets sufficiently scrambled that the coalescing in the I/O > layer becomes ineffective. It fell off the bottom of my priority queue, sorry. -- wli - 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: Please revert 21564fd2a3deb48200b595332f9ed4c9f311f2a7
Adrian Bunk wrote:
> Linus, please revert commit 21564fd2a3deb48200b595332f9ed4c9f311f2a7
>
> It's not acceptable since illegal modules should definitely not get
> write access to paravirt_ops.
>
What's the concern? That a module will update the pv_ops structure to
repoint the function? In practice that won't work because inline
patching will have already happened, so all the callsites will have
direct calls to the appropriate function.
> Andi forwarded it although the following people had already NAK'ed it:
> - Christoph Hellwig [1]
> - Peter Zijlstra [2]
> - Alan Cox [3]
>
> Considering that Andi forwarded it 2 days after he himself said a
> different solution was pending [4] I assume he mistakenly sent it for
> inclusion in your tree.
>
We played with some ideas, but they all turned out way too ugly to live.
> Reverting is safe since it simply re-establishes the 2.6.21 status quo.
>
Well, not really. It breaks any non-GPL module when CONFIG_PARAVIRT is
enabled, even though the same module would work fine otherwise. That's
a pretty large regression.
I'm not really sure what the concerns are with exporting paravirt_ops as
a non-GPL symbol.
I think the basic arguments are:
security - it makes an obvious place to hook things in. Perhaps,
but in practice the patching code will replace all the indirect
calls with either inline code or a direct call to the proper
function. Once that's happened, changing the structure will have no
effect.
license - it makes GPL-only functions visible to non-GPL modules.
This is largely moot, since in the non-PARAVIRT case most of the
functions in question are exported from the kernel as inline code in
headers anyway, and so are available to all modules anyway. In
either case (ie PARAVIRT or no), non-inlined GPL functions will
still be unavailable to non-GPL modules, and will still cause errors
at insmod time. If a module decides to directly access paravirt_ops
(which is never a supported API, for anyone), then they could get
access to GPL code without raising a complaint - but it would be
very fragile piece of code, and definitely easily broken (it would
be not much different from jumping into the kernel at a fixed
address because it "knows" a particular function is there).
It would be possible to arrange for paravirt_ops to be largely cleared
out once patching has happened, so that anyone looking at it wouldn't
get any useful information anyway (we'd need to keep a non-exported copy
around for patching modules, but that's OK).
Or, alternatively, we could wrap parts of struct paravirt_ops with
#ifdef MODULE to obscure the entrypoints from modules. They would still
be able to get around this, of course, but it makes the intent clear
("thou shalt not play with these"). But I think its overkill, ugly, and
doesn't really achieve much in practice.
J
-
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] cciss: force ignore of responses to unsent scsi commands after kexec reboot
On Thu, Jun 14, 2007 at 03:25:23PM -0400, Neil Horman wrote: > On Thu, Jun 14, 2007 at 06:16:03PM -, Miller, Mike (OS Dev) wrote: > > > > > > > -Original Message- > > > From: Neil Horman [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, June 14, 2007 10:31 AM > > > To: linux-kernel@vger.kernel.org > > > Cc: Miller, Mike (OS Dev); ISS StorageDev; > > > [EMAIL PROTECTED]; [EMAIL PROTECTED] > > > Subject: [PATCH] cciss: force ignore of responses to unsent > > > scsi commands after kexec reboot > > > > > > Hey - > > > cciss hardware currently can continue to send responses > > > to scsi commands after the host system has undergone a kexec > > > reboot. The way the drier is currently written, reception of > > > these commands results in a BUG halt, since it can't match > > > the response to any issued command since the boot. This > > > patch corrects that by using the kexec reset_devices command > > > line paramter to force ignore any commands that it cant correlate. > > > > > > Regards > > > Neil > > > > > > Signed-off-by: Neil Horman <[EMAIL PROTECTED]> > > > > > > > > > cciss.c |8 > > > 1 file changed, 8 insertions(+) > > > > > > > > > diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c > > > index 5acc6c4..ec1c1d2 100644 > > > --- a/drivers/block/cciss.c > > > +++ b/drivers/block/cciss.c > > > @@ -2131,6 +2131,14 @@ static int add_sendcmd_reject(__u8 > > > cmd, int ctlr, unsigned long complete) > > > ctlr, complete); > > > /* not much we can do. */ > > > #ifdef CONFIG_CISS_SCSI_TAPE > > > + /* We might get notification of completion of commands > > > + * which we never issued in this kernel if this boot is > > > + * taking place after previous kernel's crash. Simply > > > + * ignore the commands in this case. > > > + */ > > > + if (reset_devices) > > > + return 0; > > > + > > > return 1; > > > } I think this is not the right usage of reset_devices parameter. This parameter instructs the driver to reset the device before going ahead with rest of the initialization before as underlying device might not be in a sane state. kexec/kdump is one of the usages and this can also be useful in the case of BIOS not doing its job. When I had proposed crash_boot parameter for kexec/kdump purposes, that time andrew had suggested that he is afraid that driver authors will use this parameter to solve all kind of problems. I think we should stick to the theme of the parameter and implement the reset routine for cciss driver instead of simply returning back. Consider the case of hypothetical scenario where somebody booted the kernel with reset_device parameter (because of unreliable bios) and if there is a problem on kernel side that after it issues the command it lost track of that (because of kernel bug) then driver will never catch that bug as upon receiving the response it will simply ignore that. Mike, you know most about this device. Can you please help out with implementing a reset routing for it? Thanks Vivek - 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] blink: Only blink when parameter is set
On Sun, 17 Jun 2007 10:39:04 +0200 Bernhard Walle wrote: > This patch in the blink driver changes the module to only blink when > the parameter 'blink' is set to true. This is to allow the module to > be compiled in the kernel and not as module. > > As the blink module was initially written for kdump, and as the kernel > is relocatable on lots of architectures, there's no need to compile a > separate kdump kernel. The blinking can now enabled via the boot > command line for the kdump kernel when necessary. > > The patch also adds some author/license information and marks the init > function as '__init'. > > Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]> > > --- > drivers/misc/blink.c | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) > > --- a/drivers/misc/blink.c > +++ b/drivers/misc/blink.c > @@ -3,6 +3,10 @@ > #include > #include > > +static int blink = 0; no need to init to 0. > +module_param(blink, bool, S_IRUGO); > +MODULE_PARM_DESC(blink, "Enable blinking (without that, the module does > nothing)\n"); unneeded "\n" --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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: Documentation - How to debug ACPI Problems
> +2. Overriding DSDT > +-- > + > +The DSDT (there is a patch also for SSDTs) can be overridden by the user. > +The tables get copied to RAM when booting and the kernel can override them > with > +alternative tables at early boot time. > + > +Historically people used to override their DSDT to workaround BIOS or even > +kernel bugs. This is a bad idea, the override functionality is for short > +term workarounds and mainly for debugging! Please always report such bugs to > +bugzilla.kernel.org or post to [EMAIL PROTECTED] if unsure. > + > +There are two possibilities to override the DSDT: > + > + - via CONFIG_ACPI_CUSTOM_DSDT (and _FILE) compile option(s) > + - via adding a customized DSDT into initramfs > + > +The second approach does not need kernel recompilation and some distributions > +provide the patch, which is not included in mainline, in their kernels. > + > +The patch and more information can be found here (many thanks to Markus > +Gaugusch and Eric Piel): > +http://gaugusch.at/kernel.shtml > + how to override the DSDT by re-compiling the upstream kernel is already documented here: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/README.ACPI It seems inconsistent to refer to the initrd patch from the in-tree Documentation, since that patch will always be out-of-tree. I would think that the in-tree Documentation would refer to specifics relating to the kernel that is actually checked into the tree with the Documentation. This assumption can probably clear up some of the wording relating to the debug flags -- we don't have to describe the old ones -- if somebody is reading this documentation, they already have the new ones:-) Asside from those specific things that describe the kernel in the tree, I'm thinking that acpi.sourceforge.net documentation would be a better place for a general HOWTO on debugging ACPI issues in general. -Len - 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: How to improve the quality of the kernel?
Michal Piotrowski wrote: > On 18/06/07, Al Boldi <[EMAIL PROTECTED]> wrote: > > Bartlomiej Zolnierkiewicz wrote: > > > On Sunday 17 June 2007, Andrew Morton wrote: > > > > We of course do want to minimise the amount of overhead for each > > > > developer. I'm a strong believer in specialisation: rather than > > > > requiring that *every* developer/maintainer integrate new steps in > > > > their processes it would be better to allow them to proceed in a > > > > close-to-usual fashion and to provide for a specialist person (or > > > > team) to do the sorts of things which you're thinking about. > > > > > > Makes sense... however we need to educate each and every developer > > > about importance of the code review and proper recognition of > > > reviewers. > > > > That's as easy to manage as is currently done with rc-regressions. > > Are you a volunteer? Probably not, as this task requires a real PRO! > It's not an easy task, there are more patches than regressions. I didn't say it was an easy task, and it probably involves a lot of stamina. But the management aspect looks rather straight forward, yet rewarding. Thanks! -- Al - 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: [ANNOUNCE] GIT 1.5.2.2
Junio C Hamano <[EMAIL PROTECTED]> wrote: > GIT v1.5.2.2 Release Notes > == > > Fixes since v1.5.2.1 > > > * Usability fix > > - git-gui is shipped with its updated blame interface. It is > rumored that the older one was not just unusable but was > active health hazard, but this one is actually pretty. > Please see for yourself. Usability fix? More like finally implemented! _Now_ we can start to work on improving its usability. ;-) -- Shawn. - 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 1/5] Add the explanation and sample of RapidIO DTS sector to the document of booting-without-of.txt file.
Hi, Kumar and Segher,
>
> > "..8641.." "..8641d.." "..8548.." "..8548e.." "..8543.."
> "..8543e.."
> > "..8572.." "..8572e.." "..8567.." "..8567e.." "..8568.." "..8568e.."
>
> You don't need to mention _all_ compatible devices in
> the "compatible" property, only the few that matter;
> typically the oldest one, and sometimes some intermediate
> device that has extra features over the original one.
>
The oldest one is difficult to find out sometime. Can we only set the
self name in dts, such as "fsl, rapidio-8641", and add this 'compatible'
property to the driver ids arrays? Such as:
static struct of_device_id of_rio_rpn_ids[] = {
{ .compatible = "fsl, rapidio-8540",},
{ .compatible = "fsl, rapidio-8560",},
{ .compatible = "fsl, rapidio-8641",},
{ .compatible = "fsl, rapidio-8548",},
{},
};
How about that?
> It isn't useful to add "compatible" entries that no OS
> probes for.
>
> >> Concrete names are good.
> >
> > While I agree concrete names are good, we put these 'blocks' in so
> > many devices that using the device to match on is pointless.
>
> You *definitely* should put the device name for _this_
> device in there, in case it needs some special workaround.
>
> > I'm all for making up a name like 'Grande', 'Del',
> 'Janeiro'. This is
> > effective what we did with gianfar. The name gets picked up pretty
> > quickly by people.
>
> That can be used as the "base" name, yes.
>
Do you have the name list? I can change my codes according them.
How about 'Mercurary', 'Venus', 'Earth', 'Mars', 'Saturn', 'Jupiter',
'Uranus', 'Neptune',
Or 'Aries', 'Taurus', 'Gemini', 'Cancer', 'Leo', 'Virgo', 'Libra',
'Scorpius', 'Sagittarius', 'Capricornus', 'Aquarius', 'Pisces' ?
Thanks!
Wei.
-
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 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Sun, 2007-06-17 at 19:08 -0700, Christoph Lameter wrote: > On Sun, 17 Jun 2007, Matt Mackall wrote: > > > Is it? Last I looked it had reverted to handing out reverse-contiguous > > pages. > > I thought that was fixed? Bill Irwin was working on it. > > But the contiguous pages usually only work shortly after boot. After > awhile memory gets sufficiently scrambled that the coalescing in the I/O > layer becomes ineffective. the buddy allocator at least defragments itself somewhat (granted, it's not perfect and the per cpu page queues spoil the game too...) -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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/
Fwd: [PATCH] [libata] Add irq_flags to struct pata_platform_info
Any comments for this patch?
Thank you.
Sonic Zhang
-- Forwarded message --
From: Sonic Zhang <[EMAIL PROTECTED]>
Date: Jun 15, 2007 5:45 PM
Subject: [PATCH] [libata] Add irq_flags to struct pata_platform_info
To: Linux IDE <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
On some embedded platforms, such as blackfin, the gpio interrupt for
IDE interface is designed to be triggered with high voltage. The gpio
port should be configured properly by set_irq_type() when register
the irq. This patch enable the generic pata platform driver to
accept platform irq flags data.
Signed-off-by: Sonic Zhang <[EMAIL PROTECTED]>
---
drivers/ata/pata_platform.c |6 --
include/linux/pata_platform.h |5 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index cbb7866..79f841b 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -139,6 +139,7 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
+ struct pata_platform_info *pp_info;
unsigned int mmio;
/*
@@ -208,11 +209,12 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
- pata_platform_setup_port(&ap->ioaddr, pdev->dev.platform_data);
+ pp_info = (struct pata_platform_info *)(pdev->dev.platform_data);
+ pata_platform_setup_port(&ap->ioaddr, pp_info);
/* activate */
return ata_host_activate(host, platform_get_irq(pdev, 0), ata_interrupt,
-0, &pata_platform_sht);
+pp_info->irq_flags, &pata_platform_sht);
}
/**
diff --git a/include/linux/pata_platform.h b/include/linux/pata_platform.h
index 2d5fd64..5799e8d 100644
--- a/include/linux/pata_platform.h
+++ b/include/linux/pata_platform.h
@@ -8,6 +8,11 @@ struct pata_platform_info {
* spacing used by ata_std_ports().
*/
unsigned int ioport_shift;
+ /*
+* Indicate platform specific irq types and initial
+* IRQ flags when call request_irq()
+*/
+ unsigned int irq_flags;
};
#endif /* __LINUX_PATA_PLATFORM_H */
--
1.5.1.3
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
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] deny partial write for loop dev fd
On Sat, Jun 16, 2007 at 07:39:17PM +0400, Dmitriy Monakhov wrote: > Partial write can be easily supported by LO_CRYPT_NONE mode, but > it is not easy in LO_CRYPT_CRYPTOAPI case, because of its block nature. > I don't know who still used cryptoapi, but theoretically it is possible. > So let's leave things as they are. Loop device doesn't support partial > write before Nick's "write_begin/write_end" patch set, and let's it > behave the same way after. OK... but just bailing out here doesn't exactly solve the problem, does it? Some data is already written at this point, so failing just means that the underlying file just gets corrupted instead. OTOH, my attempt to support partial writes isn't right anyway, because it doesn't get propogated back to the caller correctly anyway. So we'll go with your patch, thanks. > > Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]> > --- > drivers/block/loop.c |4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/block/loop.c b/drivers/block/loop.c > index 4bab9b1..de122f3 100644 > --- a/drivers/block/loop.c > +++ b/drivers/block/loop.c > @@ -244,10 +244,8 @@ static int do_lo_send_aops(struct loop_device *lo, > struct bio_vec *bvec, > > ret = pagecache_write_end(file, mapping, pos, size, copied, > page, fsdata); > - if (ret < 0) > + if (ret < 0 || ret != copied) > goto fail; > - if (ret < copied) > - copied = ret; > > if (unlikely(transfer_result)) > goto fail; > -- > 1.5.2 > - 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: [AGPGART] intel_agp: use table for device probe
On 2007.06.18 03:56:36 +, Carlo Wood wrote: > On Mon, Jun 18, 2007 at 10:57:38AM +1000, Dave Airlie wrote: > > >Right now, I'm at a loss to explain the corruption, so it's > > >difficult to suggest what to try. > > > > The thing is here, this is PCIE, so if there is a GPU plugged into the > > PCIE 16x slot in theory the main onboard graphics should disable, AGP > > code is used to control the GART for the onboard chip, in this case a > > plugged in card will not use AGP, I wonder have Intel tested with a > > pcie card in place... Agree. We seem to always enable AGP even IGD is disabled or not exists, other card should not depend on this module ever. > > That is Chinese for me :/. > Do you want me to try something? Carlo, I've just built latest kernel git tree on a Dell 965G box and have a NV card plugged-in. It boots fine. Linux agpgart interface v0.102 (c) Dave Jones agpgart: Detected an Intel 965G Chipset. agpgart: AGP aperture is 256M @ 0x0 I don't know why it hangs your machine when loading this module, it should just not bother anything. But from your last "modprobe: ..." line, it seems there's really badness somewhere, do you have serial console to see more in the message? - 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: [AGPGART] intel_agp: use table for device probe
> > The thing is here, this is PCIE, so if there is a GPU plugged into the > PCIE 16x slot in theory the main onboard graphics should disable, AGP > code is used to control the GART for the onboard chip, in this case a > plugged in card will not use AGP, I wonder have Intel tested with a > pcie card in place... That is Chinese for me :/. Do you want me to try something? Well it was more for davej's benefit, in theory for your machine with a PCIE graphics card you don't need agpgart enabled at all granted it shouldn't screw up if it is.. Dave. - 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/
PCI userland access non-mmap APIs, kernel access to legacy space
Hi folks ! Before I start actually writing code, I want to do a quick brain dump here to see if there are any objections. So a problem we have is that on non-x86, we expect to be able to access PCI IO space via mmap'ing of sysfs based "resource" files. However, there are various PCI host bridges out there that don't make that a practical solution. So far, I have two cases on ppc of bridges that either use indirect access for the IO space or require specific HW workarounds on accesses that involve spinlocks (to properly deal with the non-posted aspect of IO transactions). In addition, Lennert tells me that similar issues exist on ARM. Thus, I would like to introduce an additional read/write interface to sysfs "resource" files (and then get Ian's libpciaccess use that when mmap is unavailable). In fact, it's funny in a way becauase the "legacy" files interface is already read/write based (exclusively even, mmap isn't supported) for legacy IOs. I beleive that doing so is better than trying to extend /dev/port to understand multiple domains, >64K IO space, etc... etc, because you don't have to understand all the remapping tricks that the operating system might be doing behind the scene, just open the resource file (or the legacy file of that bus for legacy accesses) and read/write to it. Any objection ? Also, while at it, I would like to introduce a pair of in-kernel interfaces: int pci_translate_legacy_resource(struct pci_bus *bus, struct resource *res); Which takes a resource containing an absolute legacy range on that bus (for example, an IO resource with the VGA port numbers, or a memory resource with the VGA text mode aperture). That resource is then "converted" for the given PCI bus. For x86, that function would boil down to "return 0;". The reason is that on multiple domains machines, it's actually not trivial to figure out where the legacy space of a given domain is mapped, if available at all. The above function is a way to solve that problem, allowing things like vgacon to work in multi-domains setup without half of the current arch specific hacks in there. That would be also allowed to fail (some platforms can't give access to legacy memory or legacy IOs at all). We could probably even implement the pci sysfs "legacy" interface on top of these as well, thus making it generic to all platforms. Any objection there too ? Cheers, Ben. - 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 00/14] Page cache cleanup in anticipation of Large Blocksize support
On Sun, 17 Jun 2007, Matt Mackall wrote: > Is it? Last I looked it had reverted to handing out reverse-contiguous > pages. I thought that was fixed? Bill Irwin was working on it. But the contiguous pages usually only work shortly after boot. After awhile memory gets sufficiently scrambled that the coalescing in the I/O layer becomes ineffective. - 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: git-current: slub breaks s2ram with fglrx...
Could you try to boot with "slub_debug" on the kernel command line? That may help you to diagnose the problem. - 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] clarify the GPL version of contributions by Jesper Juhl in CREDITS
On Mon, Jun 18, 2007 at 02:33:02AM +0200, Jesper Juhl wrote: > Just to make things clear in the light of recent discussions. > Stuff I contribute to the Linux kernel are licensed under the terms of the > GPL version 2. > > +D: All contributions are licensed under the terms of the GPL version 2. I suspect this is the default for the vast majority of kernel developers. Perhaps it's only worth special casing those that have an interest in GPLv3, as the numbers are bound to be far lower -- if this sort of thing is judged to be a good idea, that is (It's rather interesting to note that the vast majority of GPLv3 advocates don't even have a single changeset in the kernel, yet still feel that their input on kernel licensing is somehow relevant or valid). - 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: [AGPGART] intel_agp: use table for device probe
On Mon, Jun 18, 2007 at 10:57:38AM +1000, Dave Airlie wrote: > >Right now, I'm at a loss to explain the corruption, so it's > >difficult to suggest what to try. > > The thing is here, this is PCIE, so if there is a GPU plugged into the > PCIE 16x slot in theory the main onboard graphics should disable, AGP > code is used to control the GART for the onboard chip, in this case a > plugged in card will not use AGP, I wonder have Intel tested with a > pcie card in place... That is Chinese for me :/. Do you want me to try something? -- Carlo Wood <[EMAIL PROTECTED]> - 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: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching
--- James Morris <[EMAIL PROTECTED]> wrote: > On Fri, 15 Jun 2007, Casey Schaufler wrote: > > > > > --- James Morris <[EMAIL PROTECTED]> wrote: > > > > > On my system, it takes about 1.2 seconds to label a fully checked out > > > kernel source tree with ~23,000 files in this manner > > > > That's an eternity for that many files to be improperly labeled. > > If, and the "if" didn't originate with me, your policy is > > demonstrably correct (how do you do that?) for all domains > > you could claim that the action is safe, if not ideal. > > I can't say if an evaluation team would buy the "safe" > > argument. They've been known to balk before. > > To clarify: > > We are discussing a scheme where the underlying SELinux labeling policy > always ensures a safe label on a file, and then relabeling newly created > files according to their pathnames. To counter clarify: You are saying two things: 1. The policy always ensures a safe label. 2. Files can be relabeled in a reasonable and timely manner. I have no questions about 2. It's a hack, but you've already acknowledged that and it will work, allowing for some potential cases where someone is overeager about getting a file-in-transition. Regarding 1: This is a founding premise of the arguement, that the "policy" is written correctly such that there is no case where a file gets created with an unsafe label. Given the external nature of the policy, and the number of attributes used within the policy, and the overall sophistication of the policy mechanism, how does one ... a. know that a label is "safe" b. know that a file will get a "safe" label c. know that the policy is "correctly" written as required The question is not if fixxerupperd can set things right. The question is about the properly written policy that is required to make the mechanism worth discussing. > There is no expectation that this scheme would be submitted for > certification. De-nial. > Its purpose is to merely to provide pathname-based > labeling outside of the kernel. If you already have an in-kernel labeling scheme that you trust to make the world safe until you get around to doing the labeling externally you can argue that it's good enough. But, to quote Cinderella's Stepmother, "I said "if"". Casey Schaufler [EMAIL PROTECTED] - 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: AT_ENTROPY1 and AT_ENTROPY2 values for include/linux/auxvec.h
> Hence the config option for the kernel- it's philosophy at Gentoo to > make choices available to users how they want their systems to behave, > even on the expense of added complexity and need to "understand" how > things work in the first place. While I am not opposed to choice, I am opposed to having too finegrained kernel config options. In your view, every single kernel patch would be a config option... I much rather have config options for "important" big changes, not for something this small. Another argument is that this kind of userspace interface is better off being always there or never; making this variable serves no-one. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: AT_ENTROPY1 and AT_ENTROPY2 values for include/linux/auxvec.h
Arjan van de Ven schrieb:
On Mon, 2007-06-18 at 01:40 +0200, Alexander Gabert wrote:
Hello glibc and kernel maintainers,
could you please add two AT_ entries to include/linux/auxvec.h in the
upstream kernel and the respective elf/elf.h definitions in glibc.
while I'm not per se against adding such aux vectors, I think it's a bad
mistake to make them a config option (and 2 options at that!!)
Well our glibc patch (still under development, here comes a snippet)
will conditionally check for the auxv and if not "fall back" to normal
SSP entropy:
- /* Set up the stack checker's canary. */
- uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard ();
+ /* Set up the stack checker's canary, optional kernel entropy */
+ uintptr_t stack_chk_guard;
+
+ if (GLRO(dl_entropy) != 0) {
+stack_chk_guard = GLRO(dl_entropy);
+ }
+ else {
+stack_chk_guard = _dl_setup_stack_chk_guard ();
+ }
Hence the config option for the kernel- it's philosophy at Gentoo to
make choices available to users how they want their systems to behave,
even on the expense of added complexity and need to "understand" how
things work in the first place.
If you add the aux vector behaviour as a default, there would surely be
a backport of the default behaviour to the more "Gentoo flavoured"
choice-based system of activating/deactivating it to your own needs.
For your second question, why two config options: entropy is a precious
resource and many critical apps rely on it.
Until SSPx (http://dev.gentoo.org/~pappy/sspx/ssxp.pdf) is not
available, we don't want to force users to have two vector entries with
one containing unneeded (wasted?) entropy. SSP already works good, so
if this stuff makes it's way into the kernel or kernel and glibc folks
tell me which numbers i can use, i can make my patches and add the logic
to Gentoo kernel sources and glibc.
Sincere thanks,
Alex
-
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: How to improve the quality of the kernel?
On Monday 18 June 2007, Rafael J. Wysocki wrote: > On Sunday, 17 June 2007 23:49, Bartlomiej Zolnierkiewicz wrote: > > On Sunday 17 June 2007, Andrew Morton wrote: > > > On Sun, 17 Jun 2007 20:53:41 +0200 Bartlomiej Zolnierkiewicz <[EMAIL > > > PROTECTED]> wrote: > [--snip--] > > > > > > yup, Reviewed-by: is good and I do think we should start adopting it, > > > although I haven't thought through exactly how. > > > > Adding Reviewed-by for reviews which highlighted real issues is obvious > > (with more detailed credits for noticed problems in the patch description). > > Suppose you have modified the patch as a result of a review and you post the > modified version. Is that still right to put "Reviewed-by" into it? > Personally, I don't think so, because that suggests that this particular > version of the patch has been reviewed and not the previous one. Well, if you got the "fix issues" part right it in the modified version it shouldn't really matter. ;) But yes, we may wait with adding "Reviewed-by" after the modified patch has been posted and reviewed. > > Also when somebody reviewed your patch but the discussions it turned out > > that the patch is valid - the review itself was still valuable so it would > > be appropriate to credit the reviewer by adding Reviewed-by:. > > Yes, IMO in such a case it would be appropriate to do that. > > Also, the review need not lead to any negative comments from the reviewer, > but in that case it's also appropriate to add a "Reviewed-by" to the patch. > > Generally, if someone comments my patches, I add his/her address to the next > version's CC list, which sort of documents that the reviewer was involved. > Then, if the reviewer ACKs the patch, that will be recorded. Same approach here. > I think that for "Reviewed-by" to work correctly, we ought to have a two-stage > process of accepting patches, where in the first stage the patch is reviewed > and if there are no objections, the "Reviewed-by" (or "Acked-by") records are > added to it in the next stage (the patch itself remains unmodified). > > > > On my darker days I consider treating a Reviewed-by: as a prerequisite for > > > merging. I suspect that would really get the feathers flying. > > > > Easy to workaround by a friendly mine "Reviewed-by:" for yours > > "Reviewed-by:" > > deals (without any _proper_ review being done in reality)... ;) > > > > > > I also encourage other maintainers/developers to pay more attention to > > > > adding "Acked-by"/"Reviewed-by" tags and crediting reviewers. I hope > > > > that maintainers will promote changes that have been reviewed by others > > > > by giving them priority over other ones (if the changes are on > > > > more-or-less > > > > the same importance level of course, you get the idea). > > > > > > > > Now what to do with people who ignore reviews and/or have rather high > > > > regressions/patches ratio? > > > > > > Ignoring a review would be a wildly wrong thing to do. It's so unusual > > > that I'd be suspecting a lost email or an i-sent-the-wrong-patch. > > > > It is not unusual et all. I mean patches which affect code in such way > > that it is difficult to prove it's (in)correctness without doing time > > consuming audit. > > > > ie. lets imagine doing a small patch affecting many drivers - you've tested > > it quickly on your driver/hardware, then you skip the part of verifying > > correctness of new code in other drivers and just push the patch > > > > As a patch author you can either assume "works for me" and push the patch > > or do the audit (requires good understanding of the changed code and could > > be time consuming). It is usually quite easy to find out which approach > > the author has choosen - the very sparse patch description combined with > > the changes in code behavior not mentioned in the patch description should > > raise the red flag. :) > > First of all, the author should have a good understanding of what he's doing > and why. If there are any doubts with respect to that, the patch is likely to > introduce bugs. > > This also depends on who will be handling the bug reports related to the > patch. > If that will be the patch author, then so be it. ;-) The problem is that usually Andrew/Adrian/Michal would also be involved. > > As a reviewer having enough knowledge in the area of code affected by patch > > you can see the potential problems but you can't prove them without doing > > the time consuming part. You may try to NACK the patch if you have enough > > power but you will end up being bypassed by not proving incorrectness of > > the patch (not to mention that developer will feel bad about you NACKing > > his patch). > > Well, IMHO, the author of the patch should convince _you_ that the patch is > correct, not the other way around. If you have doubts and make him think > twice of the code and he still can't prove his point, this means that he > doesn't understand what he's doing well enough. This is a ni
Re: mea culpa on the meaning of Tivoization (was: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3)
On Sunday 17 June 2007 19:11:13 Alexandre Oliva wrote: > On Jun 17, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: > >> > That accurately describes the FCC wireless rules. > >> > >> AFAIK the FCC mandates not permitting the user to tinker. It doesn't > >> mandate the vendor to retain this ability to itself. > > > > In practical terms it does since a recall/replacement in the event of > > rule changes is a bit impractical > > Indeed. But that's not a legal requirement, it's an economic reason. > > "But I need to make a profit" or "But I need to reduce costs" is no > excluse to disrespect the GPL. > > >> Therefore, per the above, FCC doesn't mandate tivoization. > > > > I'm sure you can find a definition to sort your goals whatever. > > Are you per chance implying that I'm twisting the definition of > tivoization? > > > You know... I now believe that would be correct. I have indeed > twisted the definition of tivoization, and I'm sorry about that. > Which is not to say that I agree that the FCC or any other law > mandates tivoization, or that tivozation is a good thing or that it is > permitted by GPLv2. Please read on. > > > After long conversations with RMS about the section on poisoned apples > and tivoization in my draft article about GPLv3 (Corresponding Sources > is the name of the section in > http://fsfla.org/svnwiki/blogs/lxo/draft/gplv3-snowwhite) I had come > to the conclusion that Tivoization amounted to: > > denying the user of the computer the freedom to run modified > versions of the Free Software in it, while retain this ability to > oneself. > > This understanding of mine had been strengthened by my understanding > of the wording and the rationale of GPLv3dd3, the wording about > technical restrictions in the rationales published along with > GPLv2dd2, and the various speeches in which the term was presented. > > Nevertheless, I consulted with him and others highly involved in the > development of GPLv3 about some of the discussions going on here, and > got responses over the past few hours that surprised me. A lot. > > So I've just went back to that discussion about my article, and to > various other cases in which RMS, Eben Moglen and others presented > Tivoization, the rationales, and so on, and I came to the conclusion > that I had experienced a subtle but very significant misunderstanding. > > I'm now convinced that a more appropriate definition would be: > > denying the user of the computer the freedom to run modified > versions of the Free Software in it, by not sharing information as > to how it could be accomplished. > > > This difference is very significant, and even more so for this > discusion, because it contradicts some of what I claimed before about > forms to use GPLed software where regulations require the user to be > unable to modify the software. > > > Let me start with an example: I bought a wireless router some time > ago, and it had a GNU+Linux distribution installed in it. No source > code or written offer for source code, though. Just want to point out that, when I read this, my reaction was "But... That is a direct violation of the GPLv2. No specific reading of the license needed." > Now, if I called the vendor next day and asked for the source code, > and they responded "sorry, I can't give you that. I threw it all > away, such that I wouldn't be able to give it to you.", they would > still be disrespecting my freedoms, as well as the license, right? Yes, they would. They are distributing a modification - in the words of the GPLv2 "a work based on the work" - without complying with the terms of the license. > You see where I'm going? Now, if they gave me the source code, but I > still couldn't install modified versions, because they introduced > technical measures with the purpose of denying me this possibility, > then the inability to modify the program wouldn't be caused by > something like a physical impossibility (something like ROM), but > rather by an active measure to trample my ability to adapt the program > and run it for any purpose. > > So, if I called them to ask how to install and run modified versions > of the GPLed programs, and they responded "sorry, I can't give you > that. I threw it all away, such that I wouldn't be able to give it to > you.", they would still be disrespecting my freedoms, as well as the > license. Not even the GPLv3dd4 - because they don't have the information anymore either. If, however, they still retained the information - in any form - they would be violating the GPLv3dd4. The GPLv2 doesn't make the actions described above - "how to install and run" - a license violation. > The reasons as to why they'd want to disrespect the freedoms don't > matter. It could be "making a profit", "complying with the law", > "abiding by contractual restrictions", anything. Imposing > restrictions to the exercise of the freedoms is not in line with the > spirit of the GPL, as such restrictions render the Softwar
Re: AT_ENTROPY1 and AT_ENTROPY2 values for include/linux/auxvec.h
On Mon, 2007-06-18 at 01:40 +0200, Alexander Gabert wrote: > Hello glibc and kernel maintainers, > > could you please add two AT_ entries to include/linux/auxvec.h in the > upstream kernel and the respective elf/elf.h definitions in glibc. while I'm not per se against adding such aux vectors, I think it's a bad mistake to make them a config option (and 2 options at that!!) Stack protector is very widely deployed today (Fedora,RHEL,SLES,OpenSUSE,Gentoo etc), so I can sure see the point of helping it a bit... but I'd like to see a little more data on how the current approach isn't sufficient. - 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: mea culpa on the meaning of Tivoization
On Jun 17, 2007, Alan Cox <[EMAIL PROTECTED]> wrote:
>> > In practical terms it does since a recall/replacement in the event of
>> > rule changes is a bit impractical
>>
>> Indeed. But that's not a legal requirement, it's an economic reason.
> Cynical Economists would argue 'legal requirements' are just changes to
> the cost of the various economic options. Sometimes when I look at
> Microsoft's approach to various cases it seems they think that way too.
I guess this depends to some point on the kind of penalties you face.
If they're only economic, then yes. If you may end up going to jail
or some such, I think the picture gets different. But yes, that's a
way to see it, and I know we're not alone in perceiving some behaviors
that way.
> I can tell you how to upgrade it ("you can't") yet I as the manufacturer
> can issue new units with modified code so I still control it even though
> it is meant to be "free"
The GPL has never prohibited the distribution of software in ROM, just
like it's never prohibited the fixation of software in CD-ROMs. So
explicitly permitting is not a step back in terms of defending
freedoms, even if there might be something to do that would advance
freedoms in this field.
Anyhow, AFAIK software in ROM is not non-Free Software. That it's
impossible to modify/replace/whathaveyou it is not the result of a
restriction that someone is imposing on you.
It's the difference between "you can't fly because you don't have
wings" and "you won't fly because I've tied your wings". With tied
wings, you're evidently not free to fly any more. But if the problem
is that you don't have wings, if you're free and sufficiently
creative, you may be able to invent baloons, airplanes, rockets et al
and overcome the barriers that nature poses for you.
--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
-
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: [AGPGART] intel_agp: use table for device probe
Right now, I'm at a loss to explain the corruption, so it's difficult to suggest what to try. The thing is here, this is PCIE, so if there is a GPU plugged into the PCIE 16x slot in theory the main onboard graphics should disable, AGP code is used to control the GART for the onboard chip, in this case a plugged in card will not use AGP, I wonder have Intel tested with a pcie card in place... Dave. - 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: And now for something _totally_ different: Linux v2.6.22-rc5
On Mon, 18 Jun 2007, Benjamin Herrenschmidt wrote: > On Sun, 2007-06-17 at 17:20 -0700, Davide Libenzi wrote: > > > > > > I didn't see anything like that in linux.git, missed Ben's patch to > > the > > > list, and mixed up your description with the original TIF_SIGPENDING > > > work. > > > > They will still race on the signal queue though. That is, if you > > create a > > signalfd and three threads are doing a read(2) over it, if a signal > > is > > sent to the thread group (tsk->signal->shared_pending), only one will > > fetch the signal. I think that's the correct behaviour anyway. > > Andrew or Linus, did you get Ben's patch? > > It might have been missed... I can resend later today. Try to put a "GPLV3" somewhere in the subject. It might have better chances to get through Linus radar these days :D - Davide - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Andrea Arcangeli <[EMAIL PROTECTED]> wrote: > Open source licenses shouldn't forbid usages, not even the blatantly > unethical ones, "evil" is not tangible (I guess everything would be > easier in life if it was). Since you mention Open source... What if I showed you that tivoization discriminates against field of endeavor? http://opensource.org/docs/osd 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. Wait, TiVo, you're saying I cannot use this modified version of the program to do $whatever in this computer you sold me, and that's solely because you don't want to let me? Is this forceful restriction on how or where the program can be used not a discrimination against fields of endeavor? It's not a restriction imposed by the license of the program, but it is a restriction imposed by the manufacturer of the equipment that distributes the program, therefore, the conditions under which the program is distributed are not only non-Free Software, they also fail to meet the Open Source definition. Neat, huh? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Once upon a time, Bron Gondwana <[EMAIL PROTECTED]> said: > To be fair here, this could also be accomplished by having to flip a > physical switch on the router, especially if you did something funky > like: > > [---] push this button for a 5 minute access pass to upload new > software through physical cable port 1. > > More complex, but not unreasonable. Well, there is no restriction on putting files on the routing engine's storage devices (flash and hard drive); it is running OpenSSH, so scp/sftp work fine, and you can drop to a shell easily. The restriction is that the kernel won't run unsigned binaries. Also, flipping physical switches is pretty much an unreasonable expectation for core router operation. These are often in other locations, sometimes other telcos' central offices (where you have to pay to have "remote hands" do something and then hope they don't screw it up). You can easily go the entire life of a device where the primary operators never physically see the device. -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. - 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: And now for something _totally_ different: Linux v2.6.22-rc5
On Sun, 2007-06-17 at 17:20 -0700, Davide Libenzi wrote: > > > > I didn't see anything like that in linux.git, missed Ben's patch to > the > > list, and mixed up your description with the original TIF_SIGPENDING > > work. > > They will still race on the signal queue though. That is, if you > create a > signalfd and three threads are doing a read(2) over it, if a signal > is > sent to the thread group (tsk->signal->shared_pending), only one will > fetch the signal. I think that's the correct behaviour anyway. > Andrew or Linus, did you get Ben's patch? It might have been missed... I can resend later today. Ben. - 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: How to improve the quality of the kernel?
Bartlomiej Zolnierkiewicz wrote: > In case of being maintainer "bastard approach" is more about not discouraging > developers by holding patches for too long than about getting credit. The maintainer who is about to suffocate in newly contributed code is actually a lucky guy: He can ask his eager contributors to also help with cross-reviewing and bug fixing, otherwise all the fine work will be stuck in the clogged pipeline. (E.g. post a subsystem todo-list now and then, as a subtle hint.) -- Stefan Richter -=-=-=== -==- =--=- http://arcgraph.de/sr/ - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Sun, 17 Jun 2007, Alexandre Oliva wrote: >> /me hands Linus a mirror > "I'm a damn handsome dude, ain't I?" Heh. I beg to differ ;-) >> Serious, what's so hard to understand about: > You're talking about something totally different. No, I'm not. You can say tivoization is *good* however much you like. This doesn't dispute in any way my claim that no tivoization would be *better*, that you'd get contributions from the people that, because of tivoization, don't feel compelled to develop and contribute, because they can't use the fruits of their efforts in the device where they would be most useful for them. > What Tivo did is *good* in my opinion! > Can't you get that through your skull? No. I disagree. We can agree to disagree on that. > They gave the software back! Be happy! They *followed* the rules. They > *followed* the tit-for-tat. But they removed incentive for far more users to do so. So you get fewer contributions than you could without tivoization. "Can't you get that through your skull?" :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: asm-sh64/module.h defines 32 bit ELF types
On Fri, Jun 15, 2007 at 01:10:40PM -0700, Jeremy Fitzhardinge wrote: > I'm doing a little cleanup of ELF stuff around the tree, and I noticed > that asm-sh64/module.h defines 32 bit versions of the ELF types rather > than 64. Is this right? > Yes, that's correct. sh64 supports both a 64-bit and a 32-bit ABI, but in practice, only the 32-bit is used (both for kernel and user space). While registers and loads/stores are 64-bits, the pointer size is still 32 when using the 32-bit ABI. This was the reason for things like ARCH_SLAB_MINALIGN. - 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: 2.6.22-rc5 regression
On Mon, Jun 18, 2007 at 02:10:49AM +0200, Carlo Wood wrote: > On Mon, Jun 18, 2007 at 08:18:58AM +0900, Paul Mundt wrote: > > The obvious question of course is whether actually reverting this > > changeset fixes your problem? I would be very surprised if it did. > > Having a git commit Id, like d09c6b809432668371b5de9102f4f9aa6a7c79cc, > how can I create a .diff file from that? > $ git show d09c6b809432668371b5de9102f4f9aa6a7c79cc | patch -p1 -R ... build and test ... $ git show d09c6b809432668371b5de9102f4f9aa6a7c79cc | patch -p1 ... back to original (or git checkout-index -f mm/page_alloc.c) ... if you just want to test that single change. > I think git bisect made an error... as you can see for yourself > with the list of tested git Id's that I gave - it didn't test > both sides of that patch imho. If you tell me how to extract a patch > then I'll manually unapply it to some failing kernel revisions and > see if that makes a difference. > Assuming that reverting that patch makes no difference, can you provide the output of 'git bisect log'? - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, Al Boldi <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> On Jun 17, 2007, Al Boldi <[EMAIL PROTECTED]> wrote: >> > Under what circumstances would it be possible to receive permission for >> > modification? >> >> You have to ask the copyright holder. >> >> Affero did just that, and so the Affero GPL was born. >> >> Just don't assume the FSF will grant such permissions lightly. > But wouldn't this be against the spirit of the GPL? I'm not sure what you mean. The moment you modified it, it would no longer be the GPL and, as long as it's not the FSF publishing it as later version of the GPL, it wouldn't be bound by the public commitment that all versions of the GPL would have the same spirit, and as long as it's not the FSF publishing it, it wouldn't be bound by the FSF's public mission and the copyright assignments it received. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: And now for something _totally_ different: Linux v2.6.22-rc5
On Sun, 17 Jun 2007, Nicholas Miell wrote: > Ah, ok, that's great. > > I didn't see anything like that in linux.git, missed Ben's patch to the > list, and mixed up your description with the original TIF_SIGPENDING > work. They will still race on the signal queue though. That is, if you create a signalfd and three threads are doing a read(2) over it, if a signal is sent to the thread group (tsk->signal->shared_pending), only one will fetch the signal. I think that's the correct behaviour anyway. Andrew or Linus, did you get Ben's patch? - Davide - 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: [AGPGART] intel_agp: use table for device probe
On Mon, Jun 18, 2007 at 02:06:43AM +0200, Carlo Wood wrote: > On Sun, Jun 17, 2007 at 06:49:18PM -0400, Dave Jones wrote: > > ok, then you must have CONFIG_AGP=y > > I do - not voluntary however. For some mysterious reason I am > unable to set it to n or m. You likely have CONFIG_IOMMU set. This makes AGP non-optional. > I am also not able to set CONFIG_AGP_INTEL > to n, only to y or m. > (using make 'menuconfig' for example). Can't explain that one. > > > Hence, in the case that the kernel works, intel-agp is loaded > > > WITHOUT printing this Detected line > > > > That doesn't make much sense. The hardware doesn't change between > > a working & not-working kernel, and somehow the PCI probing fails. > > Hmm, do you have CONFIG_EDAC set ? > > CONFIG_EDAC=m > > $ lsmod | grep edac ok, red herring. > > There's an outstanding bug (well, lack of feature) , where it claims > > the PCI device before AGP gets a chance to. > > This is unrelated to your hang however, but would at least explain > > the inconsistent probing. > > > > > Perhaps my "solution" is to remove this module completely? > > > I don't seem to need it. > > > > It's needed only for 3d, > > Nope - I just played UT2004 without problems, and without intel-agp loaded. Using the nvidia driver? It has its own built-in AGP support which will get used if the kernel AGP support is missing. > > but it'd be good to figure out why its so > > broken on your system, even if you don't need it. > > Please tell me what to do / try. > I'm an experienced coder - but I never really played with the > kernel before - so you'll have to spell out how to turn on debugging etc. Right now, I'm at a loss to explain the corruption, so it's difficult to suggest what to try. Dave -- http://www.codemonkey.org.uk - 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: And now for something _totally_ different: Linux v2.6.22-rc5
On Sun, 2007-06-17 at 16:49 -0700, Davide Libenzi wrote: > On Sun, 17 Jun 2007, Nicholas Miell wrote: > > > On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote: > > > On Sun, 17 Jun 2007, Nicholas Miell wrote: > > > > > > > On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote: > > > > > In a stunning turn of events, I've actually been able to make another > > > > > -rc > > > > > release despite all the discussion (*cough*flaming*cough*) about > > > > > other > > > > > issues, and we now have a brand-spanking-new Linux 2.6.22-rc5 release > > > > > out there! > > > > > > > > > > > > > signalfd still has the broken behavior w.r.t. signal delivery to > > > > threads. > > > > > > > > Is this going to get fixed before 2.6.22 proper is released, or should > > > > it just be disabled entirely so no userspace apps grow to depend on > > > > current wrong behavior? > > > > > > At the moment, with Ben's patch applied, signalfd can see all group-sent > > > signals, and locally-directed thread signals. > > > > But there's still no way for multiple threads to read from a single > > signalfd and get their own thread-specific signals in addition to > > process-wide signals, right? I think this was agreed to be the least > > surprising behavior. > > Multiple threads can wait on the signalfd. Each one will dequeue either > its own private signals (tsk->pending) or the process shared ones > (tsk->signal->shared_pending). This will be the behaviour once Ben's patch > is applied. > Ah, ok, that's great. I didn't see anything like that in linux.git, missed Ben's patch to the list, and mixed up your description with the original TIF_SIGPENDING work. Sorry for the confusion. -- Nicholas Miell <[EMAIL PROTECTED]> - 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/
AT_ENTROPY1 and AT_ENTROPY2 values for include/linux/auxvec.h
Hello glibc and kernel maintainers,
could you please add two AT_ entries to include/linux/auxvec.h in the
upstream kernel and the respective elf/elf.h definitions in glibc.
#define AT_ENTROPY1 24 /* kernel entropy in auxiliary vector */
#define AT_ENTROPY2 25 /* second field for kernel entropy */
The accompanying kernel patch follows, it is basically a config option
to give userland entropy.
We are using the appended patch for Gentoo Hardened.
You don't have to put it into the upstream linux kernel, it is only
there for explaining what i need the AT_ values for.
Also the patch contains a subtle "bug" because the repetive call to
get_random_int()
seems to yield the same result when done immediately after another:
$$ od -tx8 /proc/self/auxv
000 e420 e021
020 0383f9ff0010 1006
040 00640011 80340003
060 0024 000a0005
100 b7ef2007 0008
120 800013f9 000b
140 000c 000d
160 000e 0017
200 0c1f4d810018 0c1f4d810019
220 bfa7da8b000f
240
However, this is just a proof of concept, all i'm asking for is to get
the two numbers into the upstream
kernel and glibc auxvec.h to avoid future clashes with the numbers, thx
in advance.
-- patch --
diff -Nru linux-2.6.21.5.ORIG/fs/binfmt_elf.c linux-2.6.21.5/fs/binfmt_elf.c
--- linux-2.6.21.5.ORIG/fs/binfmt_elf.c 2007-06-11 20:37:06.0 +0200
+++ linux-2.6.21.5/fs/binfmt_elf.c 2007-06-18 00:22:59.0 +0200
@@ -201,6 +201,13 @@
NEW_AUX_ENT(AT_GID, tsk->gid);
NEW_AUX_ENT(AT_EGID, tsk->egid);
NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
+#if defined(CONFIG_AT_ENTROPY1)
+ NEW_AUX_ENT(AT_ENTROPY1, get_random_int());
+#endif
+#if defined(CONFIG_AT_ENTROPY2)
+ NEW_AUX_ENT(AT_ENTROPY2, get_random_int());
+#endif
+
if (k_platform) {
NEW_AUX_ENT(AT_PLATFORM,
(elf_addr_t)(unsigned long)u_platform);
diff -Nru linux-2.6.21.5.ORIG/include/linux/auxvec.h
linux-2.6.21.5/include/linux/auxvec.h
--- linux-2.6.21.5.ORIG/include/linux/auxvec.h 2007-06-11 20:37:06.0
+0200
+++ linux-2.6.21.5/include/linux/auxvec.h 2007-06-18 00:19:57.0
+0200
@@ -26,6 +26,9 @@
#define AT_SECURE 23 /* secure mode boolean */
-#define AT_VECTOR_SIZE 44 /* Size of auxiliary table. */
+#define AT_ENTROPY1 24 /* kernel entropy in auxiliary vector */
+#define AT_ENTROPY2 25 /* second field for kernel entropy */
+
+#define AT_VECTOR_SIZE 46 /* Size of auxiliary table. */
#endif /* _LINUX_AUXVEC_H */
diff -Nru linux-2.6.21.5.ORIG/security/Kconfig linux-2.6.21.5/security/Kconfig
--- linux-2.6.21.5.ORIG/security/Kconfig2007-06-11 20:37:06.0
+0200
+++ linux-2.6.21.5/security/Kconfig 2007-06-18 00:32:57.0 +0200
@@ -4,6 +4,24 @@
menu "Security options"
+config AT_ENTROPY1
+ bool "Enable kernel entropy in the auxiliary vector"
+ help
+This option provides support for kernel-generated entropy handed
+to processes via the auxiliary vector table in /proc/self/auxv.
+Most notably userlands with heavy usage of stack smashing protection
+benefit from kernel entropy because /dev/urandom is less likely to
+become depleted due to the extensive need for randomized SSP __guard.
+
+config AT_ENTROPY2
+ bool "Enable additional kernel entropy in the auxiliary vector"
+ depends on AT_ENTROPY1
+ help
+This option provides support for an additional field of kernel-generated
+entropy for userland processes. It can be used for an extension to SSP
+where a second guard value is necessary for XOR encoding control data
+residing in the stack frame of userland processes.
+
config KEYS
bool "Enable access key retention support"
help
-- /patch --
also available at
http://dev.gentoo.org/~pappy/ssp/AT_ENTROPY/linux-2.6.21.5_AT_ENTROPY.patch
Thanks again,
Alex
-
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: 2.6.22-rc5 regression
On Mon, Jun 18, 2007 at 08:18:58AM +0900, Paul Mundt wrote: > The obvious question of course is whether actually reverting this > changeset fixes your problem? I would be very surprised if it did. Having a git commit Id, like d09c6b809432668371b5de9102f4f9aa6a7c79cc, how can I create a .diff file from that? > If it does make a difference, please provide the values for > CONFIG_HOTPLUG, CONFIG_MEMORY_HOTPLUG and CONFIG_HOTPLUG_CPU from your > .config. > > I would wager that you only have CONFIG_HOTPLUG=y, in which case, the > only difference over previous kernels will be that zone_batchlist() is no > longer flagged as __init, and so it won't be freed -- this was the reason > for the "special section" comment in the changeset, as currently it's > left hanging around for folks that aren't doing cpu/memory hotplug, since > __devinit was the closest that both cpu and memory hotplug had in common. > > I can't imagine that this would impact you at all, though. I think git bisect made an error... as you can see for yourself with the list of tested git Id's that I gave - it didn't test both sides of that patch imho. If you tell me how to extract a patch then I'll manually unapply it to some failing kernel revisions and see if that makes a difference. -- Carlo Wood <[EMAIL PROTECTED]> - 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: How to improve the quality of the kernel?
On Monday 18 June 2007, Stefan Richter wrote: > Bartlomiej Zolnierkiewicz wrote: > > despite the fact that audit takes > > more time/knowledge then making the patch you will end up with zero credit > > if patch turns out to be (luckily) correct. Even if you find out issues > > and report them you are still on mercy of author for being credited > > If we introduce a "Reviewed-by" with reasonably clear semantics > (different from Signed-off-by; e.g. the reviewer is not a middle-man in > patch forwarding; the reviewer might have had remaining reservations... > very similar to but not entirely the same as "Acked-by" as currently > defined in -mm) --- and also make the already somewhat established > "Tested-by" more official, --- then the maintainers could start to make > it a habit to add Reviewed-by and Tested-by. > > Plus, reviewers and testers could formally reply with Reviewed-by and > Tested-by lines to patch postings and even could explicitly ask the > maintainer to add these lines. Sounds great. > > so from personal POV you are much better to wait and fix issues after they > > hit mainline kernel. You have to choose between being a good citizen and > > preventing kernel regressions or being bastard and getting the credit. ;) > > > > If you happen to be maintainer of the affected code the choice is similar > > with more pros for letting the patch in especially if you can't afford the > > time to do audit (and by being maintainer you are guaranteed to be heavily > > time constrained). > > I don't think that a maintainer (who signs off on patches after all) can > easily afford to take the "bastard approach". I may be naive. Well, I'm not doing it myself but I find it tempting... ;) In case of being maintainer "bastard approach" is more about not discouraging developers by holding patches for too long than about getting credit. Bart - 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: [AGPGART] intel_agp: use table for device probe
On Sun, Jun 17, 2007 at 06:49:18PM -0400, Dave Jones wrote: > ok, then you must have CONFIG_AGP=y I do - not voluntary however. For some mysterious reason I am unable to set it to n or m. I am also not able to set CONFIG_AGP_INTEL to n, only to y or m. (using make 'menuconfig' for example). > > $ find /lib/modules -name 'agpgart.ko' > > $ > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64 > -name '*agp*.ko' > > > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/sis-agp.ko > > > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/intel-agp.ko > > > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/via-agp.ko > > > > 2) > > > > $ strings > /lib/modules/2.6.22-rc5-master-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64/kernel/drivers/char/agp/intel-agp.ko > | grep 'agpgart: Detected an Intel' > > <6>agpgart: Detected an Intel %s Chipset. > > > > Hence, in the case that the kernel works, intel-agp is loaded > > WITHOUT printing this Detected line > > That doesn't make much sense. The hardware doesn't change between > a working & not-working kernel, and somehow the PCI probing fails. > Hmm, do you have CONFIG_EDAC set ? CONFIG_EDAC=m $ lsmod | grep edac $ > There's an outstanding bug (well, lack of feature) , where it claims > the PCI device before AGP gets a chance to. > This is unrelated to your hang however, but would at least explain > the inconsistent probing. > > > Perhaps my "solution" is to remove this module completely? > > I don't seem to need it. > > It's needed only for 3d, Nope - I just played UT2004 without problems, and without intel-agp loaded. > but it'd be good to figure out why its so > broken on your system, even if you don't need it. Please tell me what to do / try. I'm an experienced coder - but I never really played with the kernel before - so you'll have to spell out how to turn on debugging etc. -- Carlo Wood <[EMAIL PROTECTED]> - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, Jun 17, 2007 at 04:58:40PM -0500, Chris Adams wrote: > The reason is that if there ever is a security hole in the routing > engine software (FreeBSD kernel, OpenSSH, etc.), it would be a really > bad thing if crackers could load arbitrary software (rootkits, spam > software, etc.) directly on Internet core routers. If you think spam > zombies on cable modems or DSL are bad, imagine them on 100 megabit > links! Not sure if it's a good example, keep in mind that at the first exploitable software bug any hardware DRM breaks apart. But since you made a BSD-embedded example, this shows how the only really important thing is that by using linux instead of BSD, they can't make huge improvements or important security bugfixes to the routing engine, without us being able to incorporate them in our "home firewalls", that's the whole difference with BSD and it explains the spirit of the gpl pretty well and in the end why linux by definition can receive more contributions and in turn be technically superior. Whatever the vendor does with the gpl code is generally up to him, and if it uses the closed approach it'll allow somebody else to sell a "open" router (potentially at an higher price). Economy 101. The worry that nobody will step in and sell an "open" equivalent is a red herring. Infact I wouldn't be so certain that openmoko would exist if the current linux cellphones would be already totally open! Now I know this all probably sounds boring talk, but I think it's much closer to reality than the prospect of a trusted computing and/or DRM apocalypse. - 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] use __asm__ and __volatile__ in i386/arm/s390 byteorder.h
On Sunday 17 June 2007, Arnd Bergmann wrote: > On Monday 18 June 2007, Arjan van de Ven wrote: > > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote: > > > This changes asm() to __asm__() and volatile to __volatile__ so that > > > these headers can be used with gcc's -std=c99. > > > > hmm but the kernel doesn't use -std=c99... > > The byteorder headers are exported to user space through > include/asm-generic/Kbuild.asm, and they are used by a number > of other exported headers, so they should work with any > gcc flags that a user might want to use. yeah, sorry, i should have mentioned the point here was that these are exported headers -mike signature.asc Description: This is a digitally signed message part.
Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > On 17/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > [snip] >> Serious, what's so hard to understand about: >> no tivoization => more users able to tinker their formerly-tivoized >> computers => more users make useful modifications => more >> contributions in kind > I have to disagree. Your analysis stopped at the downside of prohibiting tivoization. You didn't analyze the potential upsides, so you may indeed come to different conclusions, and they may very well be wrong. It's very human to look only at the potential downside of an action and conclude it's a bad action. But it's more rational to look at the potential upside as well, evaluate the likelihood of each in the grand scheme of things, and then decide whether the potential upside will make up for the potential downside. > Let's say that for some reason I don't want the end users of my > device to tinker with the software inside my device. Ok, keep the *want* in mind. This is very important. > Now I think you can agree to these things being positive: Yes, even if I'd phrase them slightly differently. > The only downside is that the end user purchasing the device can't > install modified versions of the software on it. And therefore you severely limit the number of end users who might turn into contributors because of self interest in hacking the device to suit their needs. > Now let's try it in a GPLv3 universe. Since I can no longer create my > device without having to allow the end user to install modified > software on it False assumption. You can create the device using GPLv3 software in it. So your acccounting of necessary downsides is only one of the possibilities. The other possibility would be to have the program in ROM, of course, which would come with a completely different set of downsides, but that would retain all of the "these things being positive" you mentioned above. And, remember, since you merely don't *want* the end user of the device to tinker with the software, you have the option to do let them do that. And, if you do, they may find in themselves reasons and incentives to change the software in the device, and the improvements are likely to get back to the community and thus back to you. Everybody wins. This is the upside that you left out from your analysis, and from every other analysis that set out to "prove" that anti-tivoization is bad that I've seen so far. It appears that people are so concerned about whatever little they might lose from requiring respect for users' freedoms that they don't even consider what they might win, and that they *would* win if at least some of the vendors were to make an choice more favorable to their users and the community. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, Jun 17, 2007 at 04:58:40PM -0500, Chris Adams wrote: > Once upon a time, Jesper Juhl <[EMAIL PROTECTED]> said: > >Let's say I'm the owner of a company selling some device that uses a > >GPLv2 OS and some GPLv2 applications to do the job. Let's say that for > >some reason I don't want the end users of my device to tinker with the > >software inside my device. Obviously I release the source for any > >modifications I may have made, but I use the hardware to prevent users > >from installing modified versions on the device (basically I TiVO'ize > >the device). > > BTW: Another reason a vendor might lock down the device is for security. > For example, Juniper routers (which now run a significant portion of the > "core" of the Internet) run FreeBSD on the routing engine. They include > several GNU software utilities (for example gawk, diff, and gdb). > Starting with JUNOS 7.6 (IIRC), end-users can no longer build and run > their own binaries on the routing engine. This means that the GPLv2 > code cannot be modified in-place (similar to TiVo altough done using > different means). > > The reason is that if there ever is a security hole in the routing > engine software (FreeBSD kernel, OpenSSH, etc.), it would be a really > bad thing if crackers could load arbitrary software (rootkits, spam > software, etc.) directly on Internet core routers. If you think spam > zombies on cable modems or DSL are bad, imagine them on 100 megabit > links! To be fair here, this could also be accomplished by having to flip a physical switch on the router, especially if you did something funky like: [---] push this button for a 5 minute access pass to upload new software through physical cable port 1. More complex, but not unreasonable. Bron. - 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: And now for something _totally_ different: Linux v2.6.22-rc5
On Sun, 17 Jun 2007, Nicholas Miell wrote: > On Sun, 2007-06-17 at 10:01 -0700, Davide Libenzi wrote: > > On Sun, 17 Jun 2007, Nicholas Miell wrote: > > > > > On Sat, 2007-06-16 at 20:33 -0700, Linus Torvalds wrote: > > > > In a stunning turn of events, I've actually been able to make another > > > > -rc > > > > release despite all the discussion (*cough*flaming*cough*) about other > > > > issues, and we now have a brand-spanking-new Linux 2.6.22-rc5 release > > > > out there! > > > > > > > > > > signalfd still has the broken behavior w.r.t. signal delivery to > > > threads. > > > > > > Is this going to get fixed before 2.6.22 proper is released, or should > > > it just be disabled entirely so no userspace apps grow to depend on > > > current wrong behavior? > > > > At the moment, with Ben's patch applied, signalfd can see all group-sent > > signals, and locally-directed thread signals. > > But there's still no way for multiple threads to read from a single > signalfd and get their own thread-specific signals in addition to > process-wide signals, right? I think this was agreed to be the least > surprising behavior. Multiple threads can wait on the signalfd. Each one will dequeue either its own private signals (tsk->pending) or the process shared ones (tsk->signal->shared_pending). This will be the behaviour once Ben's patch is applied. - Davide - 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/
[2.6 patch] mm/slab.c: start_cpu_timer() should be __cpuinit
start_cpu_timer() should be __cpuinit (which also matches what it's
callers are).
__devinit didn't cause problems, it simply wasted a few bytes of memory
for the common CONFIG_HOTPLUG_CPU=n case.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch has been sent on:
- 28 Apr 2007
--- linux-2.6.21-rc7-mm2/mm/slab.c.old 2007-04-28 14:26:44.0 +0200
+++ linux-2.6.21-rc7-mm2/mm/slab.c 2007-04-28 14:26:54.0 +0200
@@ -948,7 +948,7 @@
* the CPUs getting into lockstep and contending for the global cache chain
* lock.
*/
-static void __devinit start_cpu_timer(int cpu)
+static void __cpuinit start_cpu_timer(int cpu)
{
struct delayed_work *reap_work = &per_cpu(reap_work, cpu);
-
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: mea culpa on the meaning of Tivoization (was: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3)
> > In practical terms it does since a recall/replacement in the event of
> > rule changes is a bit impractical
>
> Indeed. But that's not a legal requirement, it's an economic reason.
Cynical Economists would argue 'legal requirements' are just changes to
the cost of the various economic options. Sometimes when I look at
Microsoft's approach to various cases it seems they think that way too.
> denying the user of the computer the freedom to run modified
> versions of the Free Software in it, by not sharing information as
> to how it could be accomplished.
That's a nice definition but one I can see being sort of abusable
depending how you read it. We head ever more into the disposable computer
era where as a vendor putting the code on ROM is cheap and upgrades don't
matter (throw it away get a new one).
I can tell you how to upgrade it ("you can't") yet I as the manufacturer
can issue new units with modified code so I still control it even though
it is meant to be "free"
-
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/
[-mm patch] arch/i386/video/fbdev.c should #include
Every file should include the headers containing the prototypes for
it's global functions.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
--- linux-2.6.22-rc4-mm2/arch/i386/video/fbdev.c.old2007-06-17
15:48:25.0 +0200
+++ linux-2.6.22-rc4-mm2/arch/i386/video/fbdev.c2007-06-17
15:48:53.0 +0200
@@ -11,6 +11,8 @@
#include
#include
+#include
+
int fb_is_primary_device(struct fb_info *info)
{
struct device *device = info->device;
-
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/
[2.6 patch] kernel/sys_ni.c should #include
Every file should include the headers containing the prototypes for it's global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.22-rc4-mm2/kernel/sys_ni.c.old2007-06-17 16:03:11.0 +0200 +++ linux-2.6.22-rc4-mm2/kernel/sys_ni.c2007-06-17 16:03:30.0 +0200 @@ -1,6 +1,7 @@ #include #include +#include #include - 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/
[2.6 patch] include/linux/kprobes.h: always offer show_registers() prototype
Allow gcc to perform show_registers() type checking also with
CONFIG_KPROBES=n.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch has been sent on:
- 27 Apr 2007
- 27 Mar 2007
include/linux/kprobes.h |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.21-rc4-mm1/include/linux/kprobes.h.old2007-03-26
15:28:27.0 +0200
+++ linux-2.6.21-rc4-mm1/include/linux/kprobes.h2007-03-26
15:32:23.0 +0200
@@ -163,7 +163,6 @@
extern void arch_arm_kprobe(struct kprobe *p);
extern void arch_disarm_kprobe(struct kprobe *p);
extern int arch_init_kprobes(void);
-extern void show_registers(struct pt_regs *regs);
extern kprobe_opcode_t *get_insn_slot(void);
extern void free_insn_slot(kprobe_opcode_t *slot, int dirty);
extern void kprobes_inc_nmissed_count(struct kprobe *p);
@@ -241,4 +240,7 @@
{
}
#endif /* CONFIG_KPROBES */
+
+void show_registers(struct pt_regs *regs);
+
#endif /* _LINUX_KPROBES_H */
-
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/
[2.6 patch] fs/namespace.c should #include "internal.h"
Every file should include the headers containing the prototypes for it's global functions. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- --- linux-2.6.22-rc4-mm2/fs/namespace.c.old 2007-06-17 15:24:24.0 +0200 +++ linux-2.6.22-rc4-mm2/fs/namespace.c 2007-06-17 15:24:50.0 +0200 @@ -28,6 +28,7 @@ #include #include #include "pnode.h" +#include "internal.h" /* spinlock for vfsmount related operations, inplace of dcache_lock */ __cacheline_aligned_in_smp DEFINE_SPINLOCK(vfsmount_lock); - 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/
[2.6 patch] fix devres_release_all() return value
Every file should include the headers containing the prototypes for
it's global functions.
Since the GNU C compiler is now able to detect that the function
prototype of devres_release_all() in the header and the actual function
disagree regarding the return value, this patch also fixes this bug.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/base/base.h |2 +-
drivers/base/devres.c |2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
--- linux-2.6.22-rc4-mm2/drivers/base/base.h.old2007-06-17
15:37:21.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/base/base.h2007-06-17 15:37:34.0
+0200
@@ -44,6 +44,6 @@
extern char *make_class_name(const char *name, struct kobject *kobj);
-extern void devres_release_all(struct device *dev);
+extern int devres_release_all(struct device *dev);
extern struct kset devices_subsys;
--- linux-2.6.22-rc4-mm2/drivers/base/devres.c.old 2007-06-17
15:30:48.0 +0200
+++ linux-2.6.22-rc4-mm2/drivers/base/devres.c 2007-06-17 15:31:03.0
+0200
@@ -10,6 +10,8 @@
#include
#include
+#include "base.h"
+
struct devres_node {
struct list_headentry;
dr_release_trelease;
-
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/
[2.6 patch] proper prototype for proc_nr_files()
This patch adds a proper prototype for proc_nr_files() in
include/linux/fs.h
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/fs.h |5 +
kernel/sysctl.c|4 +---
2 files changed, 6 insertions(+), 3 deletions(-)
--- linux-2.6.22-rc4-mm2/include/linux/fs.h.old 2007-06-17 03:50:01.0
+0200
+++ linux-2.6.22-rc4-mm2/include/linux/fs.h 2007-06-17 03:56:37.0
+0200
@@ -302,6 +302,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2116,5 +2117,9 @@
{ }
#endif /* CONFIG_SECURITY */
+int proc_nr_files(ctl_table *table, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos);
+
+
#endif /* __KERNEL__ */
#endif /* _LINUX_FS_H */
--- linux-2.6.22-rc4-mm2/kernel/sysctl.c.old2007-06-17 03:51:37.0
+0200
+++ linux-2.6.22-rc4-mm2/kernel/sysctl.c2007-06-17 03:51:51.0
+0200
@@ -47,13 +47,11 @@
#include
#include
#include
+#include
#include
#include
-extern int proc_nr_files(ctl_table *table, int write, struct file *filp,
- void __user *buffer, size_t *lenp, loff_t *ppos);
-
#ifdef CONFIG_X86
#include
#include
-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, Jun 17, 2007 at 04:46:44PM -0300, Alexandre Oliva wrote: > My perception is that the first easily dominates the second, and so > you are better off without tivoization. Your perception is quite flawed. I see where you come from, I know your intentions are absolutely genuine, but there's not a chance that by changing the GPL in any way you want, you can move the needle on companies whose only real long term threat is so broad and fundamental as the very existence of the Internet! Stay away from any DRM issue since that is not a licensing problem, and is a problem that is up to the economy to solve, all we have to do is to write good code and grow the userbase, those discussions are a total waste of time, and infact they're in the interest of the pro-DRM people. See apple removal of drm mandated by market forces (sure not mandated by the threat of GPLv3 ;). Then (besides tivo that as said at the top is not a problem at all regardless if it's legal or not with gplv2) there's the myth of trusted computing apocalypse that promises an unbreakable DRM and no computer capable of running a modified linux anymore, which cannot materialize. At every respectable linux user group there's somebody giving that TC speech. The thing, if I'm wrong and it really happens, it means something went so fundamentally wrong that the symptom will be a totally minor problem compared to the real cause that triggered it. If nothing else wait the scenario to remotely materialize before declaring preventive war to something purely theoretical, and _then_ release a v4 addressing it. If all conspiracy theories should be added to v3 as potential threat, then I would recommend to as well add a clause that if you're an alien that wants to use some GPLv3 code in your alien-technology-driven ship built to destroy planet earth, you can't unless you provide us with a copy of your ship open specifications showing how to upload our improved GPLv3 software to it, so we have a chance to build one too to defend ourself LOL. Doesn't that sound fair enough too? I mean just in case ;) Back to the tivoization issue, the crypto key is the least of the problems, the major linux cellphone vendor ships binary only modules and I wouldn't even know how to upgrade the kernel regardless of any crypto signature and even ignoring the binary only modules. If selling the locked embedded package allows new market segments to grow around linux (even if that's not _yet_ an ideal hacker-hackable cellphone) that's still a net-positive because it sends a message to the venture capital that may exploit the fact they're closed to grow market share (see openmoko, not a "perception" of mine). Open source licenses shouldn't forbid usages, not even the blatantly unethical ones, "evil" is not tangible (I guess everything would be easier in life if it was). Let's tackle on the only real _tangible_ problem of gplv2 known todate, that they can address with a few liner fix to gplv2. They should _only_ do that, and release quickly a strightforward v3 that nobody could ever pretend to argue about (they should have done that already, more than half an year passed already and most of the time at least here has been spent on purely theoretical things). They still can do the right thing. All this arguing, busybox forking, are all signals that something is wrong, it should start to ring a bell. Frankly I think we all love the FSF and the GPL and we want to help to avoid mistakes (I know I do). I'm totally in favor to __experiment__ with the DRM clause but do that on a new license. Leave GPL as it has always been, it works just great, fix the only single tangible issue known todate, the rest is all about conspiracy theories and at definining evil. Perfect fairness cannot be obtained in this world, no matter what license or system you apply. Those developers that have been so totally trustful and used "any later version" deserve better treatment (they deserve a quick fix too) and you should obey to the promise of only modification in detail according to point 9 or the "any later version" will not be enforceable because outlawing a single usage means going the opposite route of "promoting the reuse of the software" (written in gplv2, search for it). This whole email is irrelevant with the fact tivo may or may not be legal with gplv2 depending on different countries. The single attempt of trying to reduce the gpl userbase with new restriction, doesn't qualify as a modification in detail here. For the record, I said the first time quite anonymously in my blog back in Oct 06. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Sun, 17 Jun 2007, Alexandre Oliva wrote: > > A third way of stating it is "software for software". No, the romans never > > said that, but I just did, to make it just more obvious that the whole > > point is that you are expected to answer IN KIND! > > Yes. And this was precisely what meant when I wrote "quid-pro-quo" > above. Ok, so we're on the same page. "software for software". > > "You are either terminally stupid, or you're not allowing yourself > > to see an obvious argument, because it destroys your world-view". > > > > The latter is very possible. It's a very human thing. > > /me hands Linus a mirror "I'm a damn handsome dude, ain't I?" > Serious, what's so hard to understand about: You're talking about something totally different. Answer my argument: - I think Tivoization is *good*. - Your license stops something *good*. Ergo: - Your license is *bad*. > Wrong. It enables copyright holders to decide whether forgiveness is > appropriate, rather than forcing them to forgive. Being forced to > forgive deception is not tit-for-tat, and it's a losing strategy. There is NOTHING TO FORGIVE! Your whole idiotic argument misses the point: What Tivo did is *good* in my opinion! Can't you get that through your skull? They gave the software back! Be happy! They *followed* the rules. They *followed* the tit-for-tat. Linus - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
On Jun 17, 2007, [EMAIL PROTECTED] wrote: > you argue that it is evil for tivo to produce a pice of hardware that > they can modify and the user can't s/evil/unethical/, because I understand that denying people the ability to enjoy the four freedoms of Free Software is unethical, and accepting such restrictions is immoral. > but you then argue that it's a good thing for the FSF to produce a > license that they can modify and others can't A License is not software. The ethical and moral principles involved are different. I can see why I may have misled you into this, with the argument that patching and fixing bugs and upgrading licenses is as important as doing that to the software. But a license, and in particular the GPL, is not only a legal document, it's also a political statement. You'll see that articles, speeches, etc, published by Richard Stallman, by the FSF, by myself, and by many other people who defend Free Software on moral grounds don't grant permissions for people to enjoy the four freedoms. You don't want people to take your opinions and modify them. Since literary works, music, movies, paintings, and other copyrightable works, don't quite have the same dual nature of software (both a form of expression and a tool to perform technical jobs), demanding the four freedoms for all of them is not only unnecessary, it may actually be counter-productive. You'll see that even the GNU Free Documentation License refrains from insisting that the entire work be modifiable. Heck, even the GPL has some restrictions on what you can change. So, yes, the situation is different, and it smells like "it's not fair", but to me this is very clearly comparing apples and oranges. Consider it just for a moment longer: I write software from scratch. It's all mine. I want to publish it. I need a license. I look at the GPL. It doesn't say what I want. Hey, I think, it would be nice if I could modify it such that it said what I wanted. Hmm, I'd have to ask the FSF, and they might say no. I'll be better off using some other license. I know I can. I put together a computer using various pre-existing hardware and software components. Some of them demand me to respect other users' freedoms. I want to sell it. Some components don't do what I want. Cool, I can modify them, and I don't even have to ask the owner for permission. I know I can. But hey, I think, it would be nice if I could stop users from changing the software in this computer. I'd be better off if the software had some other license, but I'll take the risk and hope this will do. I bought a computer containing various hardware and software components. The computer doesn't quite do what I want. Hey, I think, it would be nice if I could modify it such that it did what I wanted. I know I can. But, heck, after I made the change, this thing won't boot any more, and I can't figure out what I did wrong. Aah, the manufacturer prohibits me from running modified versions. I don't think they can or should, but there's nothing I can do about it. I'm stuck. Oh well... > in the second case the FSF is trying to convince everyone that anyone > who produced code under the fist license, but didn't give the FSF the > ability to relicense their code to whatever the FSF wants are > misguided fools who just don't understand what they are doing. I don't understand why you think the FSF is doing this. As for myself (I'm not FSF, I'm not even a member of the FSF), I'm not doing this, and I hope you'll agree that I'm not. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - 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] use __asm__ and __volatile__ in i386/arm/s390 byteorder.h
On Monday 18 June 2007, Arjan van de Ven wrote: > > On Sun, 2007-06-17 at 18:33 -0400, Mike Frysinger wrote: > > This changes asm() to __asm__() and volatile to __volatile__ so that these > > headers can be used with gcc's -std=c99. > > hmm but the kernel doesn't use -std=c99... The byteorder headers are exported to user space through include/asm-generic/Kbuild.asm, and they are used by a number of other exported headers, so they should work with any gcc flags that a user might want to use. Arnd <>< - 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: 2.6.22-rc5 regression
On Sun, Jun 17, 2007 at 11:49:05PM +0200, Carlo Wood wrote: > Kernels that work do NOT print "agpgart: Detected an Intel > 965G Chipset." (All I know is that I have an ASUS P5B motherboard > with a iP965, whether it's this 'G' or not I don't know). > The obvious question of course is whether actually reverting this changeset fixes your problem? I would be very surprised if it did. If it does make a difference, please provide the values for CONFIG_HOTPLUG, CONFIG_MEMORY_HOTPLUG and CONFIG_HOTPLUG_CPU from your .config. I would wager that you only have CONFIG_HOTPLUG=y, in which case, the only difference over previous kernels will be that zone_batchlist() is no longer flagged as __init, and so it won't be freed -- this was the reason for the "special section" comment in the changeset, as currently it's left hanging around for folks that aren't doing cpu/memory hotplug, since __devinit was the closest that both cpu and memory hotplug had in common. I can't imagine that this would impact you at all, though. - 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: How to improve the quality of the kernel?
Bartlomiej Zolnierkiewicz wrote: > despite the fact that audit takes > more time/knowledge then making the patch you will end up with zero credit > if patch turns out to be (luckily) correct. Even if you find out issues > and report them you are still on mercy of author for being credited If we introduce a "Reviewed-by" with reasonably clear semantics (different from Signed-off-by; e.g. the reviewer is not a middle-man in patch forwarding; the reviewer might have had remaining reservations... very similar to but not entirely the same as "Acked-by" as currently defined in -mm) --- and also make the already somewhat established "Tested-by" more official, --- then the maintainers could start to make it a habit to add Reviewed-by and Tested-by. Plus, reviewers and testers could formally reply with Reviewed-by and Tested-by lines to patch postings and even could explicitly ask the maintainer to add these lines. > so from personal POV you are much better to wait and fix issues after they > hit mainline kernel. You have to choose between being a good citizen and > preventing kernel regressions or being bastard and getting the credit. ;) > > If you happen to be maintainer of the affected code the choice is similar > with more pros for letting the patch in especially if you can't afford the > time to do audit (and by being maintainer you are guaranteed to be heavily > time constrained). I don't think that a maintainer (who signs off on patches after all) can easily afford to take the "bastard approach". I may be naive. -- Stefan Richter -=-=-=== -==- =--=- http://arcgraph.de/sr/ - 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/
mea culpa on the meaning of Tivoization (was: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3)
On Jun 17, 2007, Alan Cox <[EMAIL PROTECTED]> wrote: >> > That accurately describes the FCC wireless rules. >> >> AFAIK the FCC mandates not permitting the user to tinker. It doesn't >> mandate the vendor to retain this ability to itself. > In practical terms it does since a recall/replacement in the event of > rule changes is a bit impractical Indeed. But that's not a legal requirement, it's an economic reason. "But I need to make a profit" or "But I need to reduce costs" is no excluse to disrespect the GPL. >> Therefore, per the above, FCC doesn't mandate tivoization. > I'm sure you can find a definition to sort your goals whatever. Are you per chance implying that I'm twisting the definition of tivoization? You know... I now believe that would be correct. I have indeed twisted the definition of tivoization, and I'm sorry about that. Which is not to say that I agree that the FCC or any other law mandates tivoization, or that tivozation is a good thing or that it is permitted by GPLv2. Please read on. After long conversations with RMS about the section on poisoned apples and tivoization in my draft article about GPLv3 (Corresponding Sources is the name of the section in http://fsfla.org/svnwiki/blogs/lxo/draft/gplv3-snowwhite) I had come to the conclusion that Tivoization amounted to: denying the user of the computer the freedom to run modified versions of the Free Software in it, while retain this ability to oneself. This understanding of mine had been strengthened by my understanding of the wording and the rationale of GPLv3dd3, the wording about technical restrictions in the rationales published along with GPLv2dd2, and the various speeches in which the term was presented. Nevertheless, I consulted with him and others highly involved in the development of GPLv3 about some of the discussions going on here, and got responses over the past few hours that surprised me. A lot. So I've just went back to that discussion about my article, and to various other cases in which RMS, Eben Moglen and others presented Tivoization, the rationales, and so on, and I came to the conclusion that I had experienced a subtle but very significant misunderstanding. I'm now convinced that a more appropriate definition would be: denying the user of the computer the freedom to run modified versions of the Free Software in it, by not sharing information as to how it could be accomplished. This difference is very significant, and even more so for this discusion, because it contradicts some of what I claimed before about forms to use GPLed software where regulations require the user to be unable to modify the software. Let me start with an example: I bought a wireless router some time ago, and it had a GNU+Linux distribution installed in it. No source code or written offer for source code, though. Now, if I called the vendor next day and asked for the source code, and they responded "sorry, I can't give you that. I threw it all away, such that I wouldn't be able to give it to you.", they would still be disrespecting my freedoms, as well as the license, right? You see where I'm going? Now, if they gave me the source code, but I still couldn't install modified versions, because they introduced technical measures with the purpose of denying me this possibility, then the inability to modify the program wouldn't be caused by something like a physical impossibility (something like ROM), but rather by an active measure to trample my ability to adapt the program and run it for any purpose. So, if I called them to ask how to install and run modified versions of the GPLed programs, and they responded "sorry, I can't give you that. I threw it all away, such that I wouldn't be able to give it to you.", they would still be disrespecting my freedoms, as well as the license. The reasons as to why they'd want to disrespect the freedoms don't matter. It could be "making a profit", "complying with the law", "abiding by contractual restrictions", anything. Imposing restrictions to the exercise of the freedoms is not in line with the spirit of the GPL, as such restrictions render the Software non-Free. The conclusion? Throwing keys away, or using split-key techniques, as I have suggested as potential alternatives to ROM for compliance with GPLv3 are not meant to be permitted by GPLv3. There might be practical advantages to compromising and permitting these techniques, but that would amount to endorsing disrespect for users' freedoms, and more, betraying those who licensed their works under GPLv1+ or v2+ with an intent to not permit these practices. I don't think FSF is willing to be part of this, and this is how it should be. As for those who didn't mean the GPL this way, they can always grant additional permissions, or simply refrain from enforcing the license in these cases. I apologize for my terrible misunderstanding, and for spreading it. Hopefully this message will reach everyone I have
Re: How to improve the quality of the kernel?
On Sunday, 17 June 2007 23:49, Bartlomiej Zolnierkiewicz wrote: > On Sunday 17 June 2007, Andrew Morton wrote: > > On Sun, 17 Jun 2007 20:53:41 +0200 Bartlomiej Zolnierkiewicz <[EMAIL > > PROTECTED]> wrote: [--snip--] > > > > yup, Reviewed-by: is good and I do think we should start adopting it, > > although I haven't thought through exactly how. > > Adding Reviewed-by for reviews which highlighted real issues is obvious > (with more detailed credits for noticed problems in the patch description). Suppose you have modified the patch as a result of a review and you post the modified version. Is that still right to put "Reviewed-by" into it? Personally, I don't think so, because that suggests that this particular version of the patch has been reviewed and not the previous one. > Also when somebody reviewed your patch but the discussions it turned out > that the patch is valid - the review itself was still valuable so it would > be appropriate to credit the reviewer by adding Reviewed-by:. Yes, IMO in such a case it would be appropriate to do that. Also, the review need not lead to any negative comments from the reviewer, but in that case it's also appropriate to add a "Reviewed-by" to the patch. Generally, if someone comments my patches, I add his/her address to the next version's CC list, which sort of documents that the reviewer was involved. Then, if the reviewer ACKs the patch, that will be recorded. I think that for "Reviewed-by" to work correctly, we ought to have a two-stage process of accepting patches, where in the first stage the patch is reviewed and if there are no objections, the "Reviewed-by" (or "Acked-by") records are added to it in the next stage (the patch itself remains unmodified). > > On my darker days I consider treating a Reviewed-by: as a prerequisite for > > merging. I suspect that would really get the feathers flying. > > Easy to workaround by a friendly mine "Reviewed-by:" for yours "Reviewed-by:" > deals (without any _proper_ review being done in reality)... ;) > > > > I also encourage other maintainers/developers to pay more attention to > > > adding "Acked-by"/"Reviewed-by" tags and crediting reviewers. I hope > > > that maintainers will promote changes that have been reviewed by others > > > by giving them priority over other ones (if the changes are on > > > more-or-less > > > the same importance level of course, you get the idea). > > > > > > Now what to do with people who ignore reviews and/or have rather high > > > regressions/patches ratio? > > > > Ignoring a review would be a wildly wrong thing to do. It's so unusual > > that I'd be suspecting a lost email or an i-sent-the-wrong-patch. > > It is not unusual et all. I mean patches which affect code in such way > that it is difficult to prove it's (in)correctness without doing time > consuming audit. > > ie. lets imagine doing a small patch affecting many drivers - you've tested > it quickly on your driver/hardware, then you skip the part of verifying > correctness of new code in other drivers and just push the patch > > As a patch author you can either assume "works for me" and push the patch > or do the audit (requires good understanding of the changed code and could > be time consuming). It is usually quite easy to find out which approach > the author has choosen - the very sparse patch description combined with > the changes in code behavior not mentioned in the patch description should > raise the red flag. :) First of all, the author should have a good understanding of what he's doing and why. If there are any doubts with respect to that, the patch is likely to introduce bugs. This also depends on who will be handling the bug reports related to the patch. If that will be the patch author, then so be it. ;-) > As a reviewer having enough knowledge in the area of code affected by patch > you can see the potential problems but you can't prove them without doing > the time consuming part. You may try to NACK the patch if you have enough > power but you will end up being bypassed by not proving incorrectness of > the patch (not to mention that developer will feel bad about you NACKing > his patch). Well, IMHO, the author of the patch should convince _you_ that the patch is correct, not the other way around. If you have doubts and make him think twice of the code and he still can't prove his point, this means that he doesn't understand what he's doing well enough. > Now the funny thing is that despite the fact that audit takes > more time/knowledge then making the patch you will end up with zero credit > if patch turns out to be (luckily) correct. Even if you find out issues > and report them you are still on mercy of author for being credited so > from personal POV you are much better to wait and fix issues after they > hit mainline kernel. You have to choose between being a good citizen and > preventing kernel regressions or being bastard and getting the credit. ;) Unless you are the poo
