Re: [PATCH 1/2] tools/: Convert to new topic libraries

[Arnaldo Carvalho de Melo <acme@infradead.org>]

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 it more natural to prepend 'k' to 'api'
> >> as the name "api" looks too general?

> >>   - libkapifs.{a,so} /kapi/fs/fs.c

> >> (Please ignore if it's already discussed..)

> > Hmm, no, it hasn't been discussed but I assumed tools/lib/api/ being in
> > the *kernel* repository implicitly says which api functionality we're
> > collecting there. One of the main reasons to have tools/ in the kernel
> > AFAIU is to have those tools which are using its API close. Therefore,
> > tools/lib/api/ should be unambiguous.

> > libkapifs.a (and the .so version even more, for that matter, and if we
> > decide to do it one day) would probably need more distinction and the
> > "k" in "kapi" there makes more sense.

> > This is at least how I see it from here.

> Yeah I assumed you guys plan to export it to the wild. :)

> I'm OK with tools/lib/api if it lives and used only in the kernel tree.

This is the idea, no commitment to use outside tools/ living code at
this point.

Anybody can try and provide comments on his mileage, but we're still at
a too early stage for any kind of commitments.

But yeah, everybody, I think, agrees that the ball needs to keep on
rolling on the direction of avoiding code duplication for tools/ living
code.

Back to Namhyung's suggestion, yeah, tools/lib/kapi/ would consume just
one more letter and would further disambiguate things.

But this can be done later if Borislav is unconvinced at this point.

- Arnaldo