[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <0E60DB89-5757-4841-A416-D12C56413C58@linuxhacker.ru>
Date: Mon, 11 Aug 2014 21:44:47 -0400
From: Oleg Drokin <green@...uxhacker.ru>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
Andreas Dilger <andreas.dilger@...el.com>,
Peng Tao <bergwolf@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Lai Siyao <lai.siyao@...el.com>
Subject: Re: [PATCH] staging/lustre: use rcu_dereference to access rcu protected current->real_parent field
On Aug 9, 2014, at 11:47 AM, Greg Kroah-Hartman wrote:
> On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote:
>>
>>> Because maybe these stats preceed the introduction of perf and other
>>> tracing/debug tools? I don't know, it's really low down on the list of
>>> reasons why lustre can't be merged out of staging at the moment, you all
>>> have much bigger issues to address first.
>>
>> I wonder what is the prioritized list you have in mind?
>
> Do I really have to spell out what is wrong with that codebase that
> needs to be fixed up? It took me 50+ patches for 3.17-rc1 to just fix
> up a _portion_ of the include file mess that is in there. Now is the
> first time the code actually _builds_ properly in the kernel tree (i.e.
> no magic header file include path modifications in Makefiles preventing
> individual files from being built correctly.)
Well, last time we discussed this topic, you said that moving most of lustre proc files
into sysfs and other suitable venues is what prevents moving lustre out of the
staging tree under fs/
There well might be include mess, but this is the first time I hear about it, and I have not seen
any build breakage or other obviously broken behavior.
I am sure there are more things too, that's why I am asking.
We are trying to deal with stuff we know about, but it's a bit harder to deal with the stuff we don't know about
that does not manifest itself in some clear way.
Bye,
Oleg--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists