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