On Wed, Dec 11, 2013 at 10:54:51AM -0300, Arnaldo Carvalho de Melo wrote:
> Not needed, there is even more flux happening as I merge bits from the
> (big) IPT patchset, so I'll cope.
Thanks!
> Will probably send a new patchset with it later today or tomorrow.
Oh boy, will the flood ever stop?!1?
Em Wed, Dec 11, 2013 at 02:30:33PM +0100, Borislav Petkov escreveu:
> On Wed, Dec 11, 2013 at 02:24:43PM +0100, Ingo Molnar wrote:
> > > I'll try to keep this moving today, together with the start of
> > > tools/lib/symbol/ ;-)
> >
> > That looks good to me as well. Lets see how well this whole
> >
On Wed, Dec 11, 2013 at 02:24:43PM +0100, Ingo Molnar wrote:
> > I'll try to keep this moving today, together with the start of
> > tools/lib/symbol/ ;-)
>
> That looks good to me as well. Lets see how well this whole
> approach works in practice. Please be on the lookout for
> anomalies/inconsiste
* Arnaldo Carvalho de Melo wrote:
> Em Wed, Dec 11, 2013 at 10:56:26AM +0100, Borislav Petkov escreveu:
> > On Tue, Dec 10, 2013 at 06:46:15PM -0700, David Ahern wrote:
> > > no longer applies to the moving target that is acme's tree.
> >
> > Of course it doesn't, with all the junk flood going
Em Wed, Dec 11, 2013 at 10:56:26AM +0100, Borislav Petkov escreveu:
> On Tue, Dec 10, 2013 at 06:46:15PM -0700, David Ahern wrote:
> > no longer applies to the moving target that is acme's tree.
>
> Of course it doesn't, with all the junk flood going in there :-)
>
> Btw, this is why I'm planning
Em Wed, Dec 11, 2013 at 10:21:07AM +0900, Namhyung Kim escreveu:
> On Tue, 10 Dec 2013 12:27:59 +0100, Borislav Petkov wrote:
> > On Tue, Dec 10, 2013 at 10:32:42AM +0900, Namhyung Kim wrote:
> >> I'm sorry to raise a naming issue again. But why the lib has 'k' and
> >> the directory doesn't? Isn't
On Tue, Dec 10, 2013 at 06:46:15PM -0700, David Ahern wrote:
> no longer applies to the moving target that is acme's tree.
Of course it doesn't, with all the junk flood going in there :-)
Btw, this is why I'm planning on sending only a small amount of patches
and hoping that acme picks them up qu
On 12/9/13, 9:14 AM, Borislav Petkov wrote:
From: Borislav Petkov
Move debugfs.* to api/fs/. We have a common tools/lib/api/ place
where the Makefile lives and then we place the headers in subdirs.
For example, all the fs-related stuff goes to tools/lib/api/fs/ from
which we get libapikfs.a (ac
Hi Borislav,
On Tue, 10 Dec 2013 12:27:59 +0100, Borislav Petkov wrote:
> On Tue, Dec 10, 2013 at 10:32:42AM +0900, Namhyung Kim wrote:
>> I'm sorry to raise a naming issue again. But why the lib has 'k' and
>> the directory doesn't? Isn't it more natural to prepend 'k' to 'api'
>> as the name "ap
On Tue, Dec 10, 2013 at 10:32:42AM +0900, Namhyung Kim wrote:
> I'm sorry to raise a naming issue again. But why the lib has 'k' and
> the directory doesn't? Isn't it more natural to prepend 'k' to 'api'
> as the name "api" looks too general?
>
> - libkapifs.{a,so} /kapi/fs/fs.c
>
> (Please ignor
Hi Borislav,
On Mon, 9 Dec 2013 17:14:23 +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Move debugfs.* to api/fs/. We have a common tools/lib/api/ place
> where the Makefile lives and then we place the headers in subdirs.
> For example, all the fs-related stuff goes to tools/lib/api/f
On Mon, Dec 09, 2013 at 11:22:45AM +0100, Jiri Olsa wrote:
> > -$(LIBLK)-clean:
> > +$(LIBAPIKFS)-clean:
> > ifeq ($(subdir),)
> > - $(call QUIET_CLEAN, liblk)
> > - @$(MAKE) -C $(LK_DIR) O=$(OUTPUT) clean >/dev/null
> > + $(call QUIET_CLEAN, LIBAPIKFS)
>
> do we want 'LIBAPIKFS' in lowerca
On Thu, Dec 05, 2013 at 05:25:51PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
SNIP
> $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS)
> install_plugins
>
> -LIBLK_SOURCES = $(wildcard $(LK_PATH)*.[ch])
> +LIBAPIKFS_SOURCES = $(wildcard $(LIB_PATH)fs/*.[ch])
>
> #
13 matches
Mail list logo
