David Woodhouse | 1 Aug 01:09 2011

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

On Sun, 2011-07-31 at 23:48 +0100, Al Viro wrote:
> Hell, no.  If you want to do it, do it the right way.  See #x86_merge in
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/um-header.git/

 255 files changed, 6848 insertions(+), 7816 deletions(-)

Absolutely, but slightly out of scope for what I was trying to do :)

I just posted a *minimal* set of changes to make the UML build system
cope; fixing the code as you've done is *definitely* the better option.
Is there a reason it didn't go upstream yet?

It just wants this, to make the CONFIG_64BIT option visible when
SUBARCH=x86 and also put it *first*.

diff --git a/arch/um/Kconfig.x86 b/arch/um/Kconfig.x86
index d31ecf3..630db12 100644
--- a/arch/um/Kconfig.x86
+++ b/arch/um/Kconfig.x86
 <at>  <at>  -1,5 +1,19  <at>  <at> 
 mainmenu "User Mode Linux/$SUBARCH $KERNELVERSION Kernel Configuration"

+config 64BIT
+	bool "Build 64-bit kernel" if SUBARCH = "x86"
+	default SUBARCH != "i386"
+        ---help---
+          Say yes to build a 64-bit kernel - formerly known as x86_64
+          Say no to build a 32-bit kernel - formerly known as i386
+
+config X86_32
(Continue reading)

David Woodhouse | 1 Aug 01:13 2011

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote:
> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to
> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux,
> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to
> arch/x86/um/Makefile.defs.  Next after that - arch/powerpc/um (and yes,
> it means resurrected uml/ppc port; for now - only ppc32, since I have no
> ppc64 boxen to test on). 

I can give you an account on a ppc64 box if that would help...

What you've done so far, with the one extra patch I just sent, seems
perfectly sufficient to make it cope with SUBARCH defaulting to x86
instead of to i386 or x86_64. Are you happy to push it before you do the
rest of the refactoring/moving?

--

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

richard -rw- weinberger | 1 Aug 01:17 2011
Picon

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

On Mon, Aug 1, 2011 at 1:13 AM, David Woodhouse <dwmw2 <at> infradead.org> wrote:
> On Sun, 2011-07-31 at 23:58 +0100, Al Viro wrote:
>> FWIW, the next step (still not pushed there) is to move arch/um/sys-x86 to
>> arch/x86/um, with arch/um/os-Linux/sys-x86 becoming arch/x86/um/os-Linux,
>> Kconfig.x86 moving to arch/x86/um/Kconfig and Makefile-x86 - to
>> arch/x86/um/Makefile.defs.  Next after that - arch/powerpc/um (and yes,
>> it means resurrected uml/ppc port; for now - only ppc32, since I have no
>> ppc64 boxen to test on).
>
> I can give you an account on a ppc64 box if that would help...

Isn't UML on ppc broken since ages?
As I don't have a ppc box I could never test it...

--

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Arnaud Lacombe | 1 Aug 01:20 2011
Picon

Re: [PATCH] kbuild: honor the ARCH setting of the existing configuration

Hi,

On Sun, Jul 31, 2011 at 6:34 PM, David Woodhouse <dwmw2 <at> infradead.org> wrote:
>> I am working with configuration for mips, sh, powerpc, arm and x86.
>> Some of them are for real board, some of them are to regress-test
>> compilers, binutils and kernel builds. Each of those config hardcode
>> the CROSS_COMPILER string and have their own build directory. In each
>> case, I want to be able to just run "make O=/src/obj/v3.0-arm
>> oldnoconfig all" without having to worry about anything else.
>
> Yes, that's a valid but *separate* problem.
yes, but I never really looked at it so far, I had the occasion now,
and did the patch.

> FWIW I usually solve this problem with a two-line GNUmakefile:
>        ARCH := arm
>        include Makefile
>
this would not work as I might ends up being multiple build in
parallel and I am an aficionados of `git clean -fdx' so the extra file
would go away.

> I haven't checked whether it works for out-of-source-tree builds; I bet
> it could be made to.
>
> I would love to see $ARCH turned into a proper configuration option.
>
I do not think this would be that hard, the main issue is that it
would heavily be cross-tree.

(Continue reading)

Axel Lin | 1 Aug 01:23 2011
Picon

[PATCH] power_supply: fix unterminated platform_device_id table for max8997_charger and max8998_charger

The platform_device_id table is supposed to be zero-terminated.

Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
---
 drivers/power/max8997_charger.c |    1 +
 drivers/power/max8998_charger.c |    1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/power/max8997_charger.c b/drivers/power/max8997_charger.c
index 7106b49..9848fb8 100644
--- a/drivers/power/max8997_charger.c
+++ b/drivers/power/max8997_charger.c
 <at>  <at>  -177,6 +177,7  <at>  <at>  static int __devexit max8997_battery_remove(struct platform_device *pdev)

 static const struct platform_device_id max8997_battery_id[] = {
 	{ "max8997-battery", 0 },
+	{ }
 };

 static struct platform_driver max8997_battery_driver = {
diff --git a/drivers/power/max8998_charger.c b/drivers/power/max8998_charger.c
index cc21fa2..4ddacb4 100644
--- a/drivers/power/max8998_charger.c
+++ b/drivers/power/max8998_charger.c
 <at>  <at>  -188,6 +188,7  <at>  <at>  static int __devexit max8998_battery_remove(struct platform_device *pdev)

 static const struct platform_device_id max8998_battery_id[] = {
 	{ "max8998-battery", TYPE_MAX8998 },
+	{ }
 };
(Continue reading)

David Woodhouse | 1 Aug 01:24 2011

Re: [PATCH 1/5] um: Use __i386__ in ifdef for vsyscall exports, not SUBARCH_i386

On Mon, 2011-08-01 at 01:17 +0200, richard -rw- weinberger wrote:
> Isn't UML on ppc broken since ages?

Since before the ppc{,64} -> powerpc merge, by the looks of it.

> As I don't have a ppc box I could never test it... 

Give SSH public key and preferred username...

--

-- 
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Axel Lin | 1 Aug 01:29 2011
Picon

[PATCH -next] power: max8997_charger.c needs module.h

power/max8997_charger.c uses interfaces from linux/module.h,
so it should include that file.  This fixes build errors.

Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
---
 drivers/power/max8997_charger.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/power/max8997_charger.c b/drivers/power/max8997_charger.c
index 9848fb8..e12b4a2 100644
--- a/drivers/power/max8997_charger.c
+++ b/drivers/power/max8997_charger.c
 <at>  <at>  -20,6 +20,7  <at>  <at> 
  */

 #include <linux/err.h>
+#include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/platform_device.h>
 #include <linux/power_supply.h>
--

-- 
1.7.4.1

Axel Lin | 1 Aug 01:41 2011
Picon

[PATCH] power_supply: max8998_charger: allow full timeout not set, leave it unchanged

Add a missing break for case 0 of pdata->timeout, otherwise it will fall
through to the default case and return error.

Signed-off-by: Axel Lin <axel.lin <at> gmail.com>
---
 drivers/power/max8998_charger.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/power/max8998_charger.c b/drivers/power/max8998_charger.c
index 4ddacb4..f793711 100644
--- a/drivers/power/max8998_charger.c
+++ b/drivers/power/max8998_charger.c
 <at>  <at>  -152,6 +152,7  <at>  <at>  static __devinit int max8998_battery_probe(struct platform_device *pdev)
 	case 0:
 		dev_dbg(max8998->dev,
 			"Full Timeout not set: leave it unchanged.\n");
+		break;
 	default:
 		dev_err(max8998->dev, "Invalid Full Timeout value\n");
 		ret = -EINVAL;
--

-- 
1.7.4.1

Dave Chinner | 1 Aug 01:47 2011

Re: xfstests 073 regression

On Sun, Jul 31, 2011 at 11:10:14PM +0800, Wu Fengguang wrote:
> On Sat, Jul 30, 2011 at 09:44:22PM +0800, Christoph Hellwig wrote:
> > This patch fixes the hang for me.
> 
> Thanks. It'd be better to get the _simple and tested_ fix into 3.1-rc1.
> (if anyone find major problems with the fix, please speak up)

Yes, I already have, a couple of hours before you sent this:

http://www.spinics.net/lists/linux-fsdevel/msg47357.html

We haven't found the root cause of the problem, and writeback cannot
hold off grab_super_passive() because writeback only holds read
locks on s_umount, just like grab_super_passive. So if
grab_super_passive is failing, there is some other, not yet
unidentified actor causing this problem....

Cheers,

Dave.
--

-- 
Dave Chinner
david <at> fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Coly Li | 1 Aug 01:52 2011
Picon

Re: [PATCH 0/2] Add inode checksum support to ext4

On 2011年07月31日 15:08, Joel Becker Wrote:
> On Sat, Jul 30, 2011 at 03:25:32PM +0800, Coly Li wrote:
>> On 2011年07月29日 21:19, Joel Becker Wrote:
>>> On Fri, Jul 29, 2011 at 03:48:45AM -0600, Andreas Dilger wrote:
>>>> On 2011-07-28, at 4:07 PM, Joel Becker wrote:
>>>>> 	We use ethernet crc32 in ocfs2.  btrfs uses crc32c.  Frankly, I
>>>>> could have used crc32c if I'd really thought about the hardware
>>>>> acceleration benefits.  I think it's a good idea for ext4.
>>>>
>>>> The problem with crc32[c] is that if you don't have hardware acceleration
>>>> it is terribly slow.
>>>
>>> 	We find ethernet crc32 just fine in ocfs2.  I use the kernel's
>>> implementation, which survives everyone's network traffic, and of course
>>> we added the triggers to jbd2 so we only have to do the calculations on
>>> read and write.
>>>
>>
>> Ext4 supports non-journal mode, and there are a few users (Google, Taobao, etc.).
>> A trigger of jbd2 may not work well for non-journal Ext4 ...
>>
>> And in non-journal mode, there is not copy of any meta data block in jbd2, we need to be
>> more careful in check summing, e.g. inode/block bitmap blocks...
> 
> 	Sure, but you could use a trigger in journaled mode and then do
> the checksums directly in the __ext4_handle_journal_dirty_*() functions
> in non-journaled mode.  Sure, it would be a little more CPU time, but
> the user picked "checksums + no journal" at mkfs time.
> 

(Continue reading)


Gmane