Re: [PATCH 3/4] ndctl: switch to tools/include/linux/{kernel, list, bitmap}.h

[Dan Williams]

On Wed, Jul 26, 2017 at 10:19 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>
>> On Wed, Jul 26, 2017 at 4:29 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>> >
>> > * Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>> >
>> >> On Tue, Jul 25, 2017 at 4:55 PM, Arnaldo Carvalho de Melo
>> >> <acme@xxxxxxxxxx> wrote:
>> >> > Em Tue, Jul 25, 2017 at 03:36:26PM -0700, Dan Williams escreveu:
>> >> >> Replace the ccan implementation of list primitives, bitmap helpers and
>> >> >> small utility macros with the common definitions available in
>> >> >> tool/include/linux.
>> >> >
>> >> > You should first add what you need in separate patches, paving the way
>> >> > to then use it, and some stuff are already there, see below:
>> >>
>> >> Ok, I'll break out those changes separately.
>> >
>> > BTW., another general observation I have is that ndctl uses autotools - while perf
>> > uses its own build system, some of which is abstracted out into tools/build/ and
>> > reused by other tooling projects as well.
>> >
>> > I despise autotools with a passion, it's slow, bloated, and encourages all sorts
>> > of bad API/ABI practices that plagues many OSS projects. I know that Linus
>> > explicitly did a Makefile based build system for Git for (I think) similar
>> > reasons.
>> >
>> > It might be a good idea to not let autotools into the kernel tooling tree, not
>> > because ndctl's use of autotools is bad in any fashion (it appears to be a fairly
>> > straightforward use), but to generally encourage good API/ABI practices in our
>> > tooling space, and to encourage enhancements to the tools/build/ infrastructure.
>>
>> That's a fair point. Regardless, autotools will be in the git history,
>> but if you'd like to see the final merge product eliminate its use, I
>> can't really argue otherwise. I was originally not concerned because
>> tools/usb/usbip/ was an existing in tree autotools user. In any event
>> if you want the autotools removal to be done out-of-tree I'll need to
>> put this effort on the back burner until 4.15.
>
> So that was another thing I wanted to suggest: why not import the current ndctl
> version as a single commit?
>
> I had a quick look, and there's quite a few of commits in the ndctl history that
> don't conform to kernel standards, such as:
>
>   ce881c1e78f6: ndctl: seed tracking
>
> which doesn't have any Signed-off-by tags.
>
> There's also commits with ambiguous titles that would be confusing in the kernel
> context - for example:
>
>   796b6f373dec: clarify copyright and license information
>
> ... which on the surface could be misunderstood as something talking about the
> kernel copyright ...
>
> Or:
>
>   e38bd36e5d0a: completion: updates for file name completion
>
> which I could initially mistake for a commit about scheduler completions ;-)
>
> Or:
>
>   2ad6a39c9ae9: Fix attribute sizes to match NFIT 0.8s2
>   cc7cb44385d3: Import initial infrastructure
>
> etc.
>
> I suppose all that could be corrected, SOBs added, titles clarified and prefixed
> with tools/ndctl, but then it wouldn't really be unmodified history anymore,
> right?
>
> At that point we might as well do a clean start - and not import ~500 extra
> commits into the kernel tree?

I think keeping the history is worth it, similar reasoning to why we
kept the btrfs history. Also, since the history is linear and already
rewritten by 'git filter-branch' to move everything to tools/ndctl/ it
wouldn't be that much more work to go clean up these few commits that
are problematic.