twitter: linux.kernel - 25 new messages in 17 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

==============================================================================
TOPIC: btrfs: use memparse
http://groups.google.com/group/linux.kernel/t/1a770cea2e03a5fb?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 3:10 am
From: Akinobu Mita

Use memparse() instead of its own private implementation.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Chris Mason <chris.mason@oracle.com>
Cc: linux-btrfs@vger.kernel.org
---
fs/btrfs/ctree.h | 1 -
fs/btrfs/ioctl.c | 2 +-
fs/btrfs/super.c | 31 +++----------------------------
3 files changed, 4 insertions(+), 30 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 2aa8ec6..52af317 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -2386,7 +2386,6 @@ void btrfs_sysfs_del_super(struct btrfs_fs_info *root);
ssize_t btrfs_listxattr(struct dentry *dentry, char *buffer, size_t size);

/* super.c */
-u64 btrfs_parse_size(char *str);
int btrfs_parse_options(struct btrfs_root *root, char *options);
int btrfs_sync_fs(struct super_block *sb, int wait);

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 645a179..c359efd 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -608,7 +608,7 @@ static noinline int btrfs_ioctl_resize(struct btrfs_root *root,
mod = 1;
sizestr++;
}
- new_size = btrfs_parse_size(sizestr);
+ new_size = memparse(sizestr, NULL);
if (new_size == 0) {
ret = -EINVAL;
goto out_unlock;
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 8a1ea6e..aa48c6b 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -95,31 +95,6 @@ static match_table_t tokens = {
{Opt_err, NULL},
};

-u64 btrfs_parse_size(char *str)
-{
- u64 res;
- int mult = 1;
- char *end;
- char last;
-
- res = simple_strtoul(str, &end, 10);
-
- last = end[0];
- if (isalpha(last)) {
- last = tolower(last);
- switch (last) {
- case 'g':
- mult *= 1024;
- case 'm':
- mult *= 1024;
- case 'k':
- mult *= 1024;
- }
- res = res * mult;
- }
- return res;
-}
-
/*
* Regular mount options parser. Everything that is needed only when
* reading in a new superblock is parsed here.
@@ -213,7 +188,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
case Opt_max_extent:
num = match_strdup(&args[0]);
if (num) {
- info->max_extent = btrfs_parse_size(num);
+ info->max_extent = memparse(num, NULL);
kfree(num);

info->max_extent = max_t(u64,
@@ -225,7 +200,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
case Opt_max_inline:
num = match_strdup(&args[0]);
if (num) {
- info->max_inline = btrfs_parse_size(num);
+ info->max_inline = memparse(num, NULL);
kfree(num);

if (info->max_inline) {
@@ -240,7 +215,7 @@ int btrfs_parse_options(struct btrfs_root *root, char *options)
case Opt_alloc_start:
num = match_strdup(&args[0]);
if (num) {
- info->alloc_start = btrfs_parse_size(num);
+ info->alloc_start = memparse(num, NULL);
kfree(num);
printk(KERN_INFO
"btrfs: allocations start at %llu\n",
--
1.6.0.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: sparc: use __ratelimit
http://groups.google.com/group/linux.kernel/t/130d5d8c57b1ec23?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 3:40 am
From: David Miller

From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Sun, 28 Feb 2010 19:58:17 +0900

> Replace open-coded rate limiting logic with __ratelimit().
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Driver core: Reduce the level of request_firmware() messages
http://groups.google.com/group/linux.kernel/t/ba1321736f5e0e2d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 4:20 am
From: "Rafael J. Wysocki"

On Sunday 28 February 2010, Jaswinder Singh Rajput wrote:
> Hello Rafael,
>
> On Sun, Feb 28, 2010 at 2:13 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> >
> > The messages from _request_firmware() informing that firmware is
> > being requested or built-in firmware is going to be used are printed
> > at KERN_INFO, which produces lots of noise on systems with huge
> > numbers of AMD CPUs. Reduce the level of these messages to
> > KERN_DEBUG to get rid of that noise.
> >
>
> Which firmware we are using is very useful information. Because of
> huge numbers of CPUs it seems noise then better provide the
> information for first cpu and for the rest of the CPUs you can show by
> KERN_DEBUG.

That would have been better indeed, but the problem is _request_firmware()
doesn't allow us to change the level of its messages on demand.

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: linux-next requirements
http://groups.google.com/group/linux.kernel/t/68d372e561eb8d5e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Feb 28 2010 4:20 am
From: "Rafael J. Wysocki"

On Sunday 28 February 2010, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> > On Saturday 27 February 2010, Ingo Molnar wrote:
> > >
> > > * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > >
> > > > > > Lets see. Over the last 60 days, I have reported 37 build errors. Of
> > > > > > these, 16 were reported against x86, 14 against ppc, 7 against other
> > > > > > archs.
> > > > >
> > > > > So only 43% of them were even relevant on the platform that 95+% of the
> > > > > Linux testers use? Seems to support the points i made.
> > > >
> > > > Well, I hope you don't mean that because the majority of bug reporters (vs
> > > > testers, the number of whom is unknown to me at least) use x86, we are free
> > > > to break the other architectures. ;-)
> > >
> > > It means exactly that: just like we 'can' break compilation with gcc296,
> > > ancient versions of binutils, odd bootloaders, can break the boot via odd
> > > hardware, etc. When someone uses that architectures then the 'easy'
> > > bugfixes will actually flow in very quickly and without much fuss
> >
> > Then I don't understand what the problem with getting them in at the
> > linux-next stage is. They are necessary anyway, so we'll need to add them
> > sooner or later and IMO the sooner the better.
>
> The problem is the dynamics and resulting (non-)cleanliness of code. We have
> architectures that have been conceptually broken for 5 years or more, but
> still those problems get blamed on the last change that 'causes' the breakage:
> the core kernel and the developers who try to make a difference.
>
> I think your perspective and your opinion is correct, while my perspective is
> real and correct as well - there's no contradiction really. Let me try to
> explain how i see it:
>
> You are working in a relatively well-designed piece of code which interfaces
> to the kernel in sane ways - kernel/power/* et al. You might break the
> cross-builds sometimes, but it's not very common, and in those cases it's
> usually your own fault and you are grateful for linux-next to have caught that
> stupidity. (i hope this a fair summary!)

Fair enough.

> I am not criticising that aspect of linux-next _at all_ - it's useful and
> beneficial - and i'd like to thank Stephen for all his hard work. Other
> aspects of linux-next useful as well: such as the patch conflict mediation
> role.

Great.

> But as it happens so often, people tend to talk more about the things that are
> not so rosy, not about the things that work well.
>
> The area i am worried about are new core kernel facilities and their
> development and extension of existing facilities. _Those_ facilities are
> affected by 'many architectures' in a different way from how you experience
> it: often we can do very correct changes to them, which still 'break' on some
> architecture due to _that architecture's conceptual fault_.
>
> Let me give you an example that happened just yesterday. My cross-testing
> found that a change in the tracing infrastructure code broke m32r and parisc.
>
> The breakage:
>
> /home/mingo/tip/kernel/trace/trace_clock.c:86: error: implicit declaration of function 'raw_local_irq_save'
> /home/mingo/tip/kernel/trace/trace_clock.c:112: error: implicit declaration of function 'raw_local_irq_restore'
> make[3]: *** [kernel/trace/trace_clock.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
>
> Is was 'caused by':
>
> 18b4a4d: oprofile: remove tracing build dependency
>
> In linux-next this would be pinned to commit 18b4a4d, which would have to be
> reverted/fixed.
>
> Where does the _real_ blame lie? Clearly in the M32R and HP/PARISC code: why
> dont they, four years after it has been introduced as a core kernel facility
> in 2006, _still_ not support raw_local_irq_save()?

OK, I see your point.

> ( A similar situation occured in this very thread a well - before the subject
> of the thread - so it's a real and present problem. We didnt even get _any_
> reaction about that particular breakage from the affected architecture ... )
>
> These situations are magnified by how certain linux-next bugs are reported:
> the 'blame' is put on the new commit that exposes that laggy nature of certain
> architectures. Often the developers even believe this false notion and feel
> guilty for 'having broken' an architecture - often an architecture that has
> not contributed a single core kernel facility _in its whole existence_.
>
> The usual end result is that the path of least resistance is taken: the commit
> is reverted or worked around, while the 'laggy' architecture can continue
> business as usual and cause more similar bugs and hickups in the future ...
>
> I.e. there is extra overhead put on clearly 'good' efforts, while 'bad'
> behavior (parasitic hanging-on, passivity, indifference) is rewarded.
> Rewarding bad behavior is very clearly harmful to Linux in many regards, and i
> speak up when i see it.
>
> So i wish linux-next balanced these things more fairly towards those areas of
> code that are actually useful: if it ignored build breakages that are due to
> architectures being lazy - in fact if it required architectures to _help out_
> with the development of the kernel.
>
> The majority of build-bugs i see trigger in cross-builds (90% of which i catch
> before they get into linux-next) are of this nature, that's why i raised it in
> such a pointed way. Your (and many other people's) experience will differ - so
> you might see this as an unjustified criticism.

Thanks a lot for the clarification.

Best,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: sched: implement try_to_wake_up_local()
http://groups.google.com/group/linux.kernel/t/8c5a103d75939b99?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Feb 28 2010 4:40 am
From: Oleg Nesterov

Wow ;)

I didn't read the whole series yet, still I'd like to ask a couple
of questions right now. Tejun, I am just trying to understand this
code.

On 02/26, Tejun Heo wrote:
>
> @@ -2438,6 +2438,10 @@ static inline void ttwu_post_activation(struct task_struct *p, struct rq *rq,
> rq->idle_stamp = 0;
> }
>

twitter

Sunday, February 28, 2010

linux.kernel - 25 new messages in 17 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts