On Monday 16 November 2009, Neil Brown wrote:
> I would take the md ones into my tree, but I suspect that if
> everyone did that we would end up with lots of conflicts in
> fs/compat_ioctl.c.
>
> So how about I just take the changes to md.c, and give you an:
>
>Acked-by: NeilBrown
>
> for t
...@lists.sourceforge.net
Cc: user-mode-linux-user@lists.sourceforge.net
Cc: Wolfram Sang
Arnd Bergmann (12):
arch/um: handle compat_ioctl in tty line driver
scsi/sg: move compat_ioctl handling into sg driver
autofs/autofs4: move compat_ioctl handling into fs
raw: partly fix compat_io
This pushes the handling of VT specific ioctls down to the
UML specific drivers so we can remove it from the common
compat_ioctl.c file.
Signed-off-by: Arnd Bergmann
Cc: Jeff Dike
Cc: Alexey Dobriyan
Cc: user-mode-linux-de...@lists.sourceforge.net
Cc: user-mode-linux-user@lists.sourceforge.net
t __builtin_unreachable() was the same
as "do {} while (1)", but this is not the case with the gcc I was using --
it just tells gcc that we don't expect to ever get here.
Signed-off-by: Arnd Bergmann
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7d10f96
On Thursday 23 May 2013, Geert Uytterhoeven wrote:
> > -config BUG
> > - bool "BUG() support" if EXPERT
> > - default y
> > - help
> > - Disabling this option eliminates support for BUG and WARN,
> > reducing
> > - the size of your kernel image and potentially q
On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> So, if you want to use this, then you should update the CONFIG_BUG text
> to include a warning to this effect:
>
> Warning: if CONFIG_BUG is turned off, and control flow reaches
> a BUG(), the system behaviour will be undefined.
On Thursday 23 May 2013, Russell King - ARM Linux wrote:
> This is the problem you guys are missing - unreachable() means "we lose
> control of the CPU at this point".
I'm absolutely aware of this. Again, the current behaviour of doing nothing
at all isn't very different from undefined behavior wh
kernel size seems absolutely worth keeping the
option, but 0.2-0.4% left for getting reproducible behavior also seems
worthwhile. The result in the patch below.
This basically loses any of the BUG() reporting, but leaves the
logic to trap and kill the task in place when CONFIG_BUG is disabled.
On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 01:19 AM, Ingo Molnar wrote:
> >
> > So I think the same principle applies to it as to any other debugging
> > code: it's fine to be able to turn debugging off. It's a performance
> > versus kernel robustness/determinism trade-off.
>
On Tuesday 28 May 2013, H. Peter Anvin wrote:
> On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
> >
> > Right, that is what the patch I just posted does.
> >
> > On a related note, I found that WARN_ON() can no longer be compiled
> > out since there is already cod
On Wednesday 03 July 2013, Chen Gang wrote:
> On 07/02/2013 06:57 PM, Geert Uytterhoeven wrote:
> > On Tue, Jul 2, 2013 at 10:00 AM, Chen Gang wrote:
> >> > On 07/02/2013 03:19 PM, Geert Uytterhoeven wrote:
> >>> >> On Tue, Jul 2, 2013 at 4:13 AM, Chen Gang
> >>> >> wrote:
> > I mean that COMPIL
On Thursday 04 July 2013, Chen Gang wrote:
> --patch begin--
>
> 'asm-generic' need provide necessary configuration checking, if can't
> pass checking, 'asm-generic' shouldn't implement it.
>
> For 'COMPILE_TEST', according to its help cont
On Friday 05 July 2013, Chen Gang F T wrote:
> Hello All:
>
> It seems 'asm-generic' dislikes 'mad users' (e.g allmodconfig,
> randconfig, and me).
>
> I guess the main reason is: 'asm-generic' thinks what mad users talk
> about is useless in real world, so it is just noisy.
>
> I can understand
.
Signed-off-by: Arnd Bergmann
---
arch/um/kernel/time.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index 7f69d17de354..052de4c8acb2 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -121,12 +121,12 @@ static
14 matches
Mail list logo
