Re: [PATCH v2] Documentation/arch: Add kernel feature descriptions and arch support status under Documentation/features/

Michael Ellerman
2015-05-18T01:37:20Z

On Fri, 2015-05-15 at 09:49 +0200, Ingo Molnar wrote:
> * Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> > On Thu, 2015-05-14 at 12:38 -0700, Andrew Morton wrote:
> > > > Add arch support matrices for more than 40 generic kernel features
> > > > that need per architecture support.
> > > >
> > > > Each feature has its own directory under Documentation/features/feature_name/,
> > > > and the arch-support.txt file shows its current arch porting status.
> > >
> > > It would be nice to provide people with commit IDs to look at, but the
> > > IDs won't be known at the time the documentation file is created. We
> > > could provide patch titles.
> >
> > +1 on patch titles.
>
> Ok, I'll solve this.

Thanks.

> > > But still, let's not overdo it - get something in there, see how
> > > well it works, evolve it over time.
> > >
> > > I don't think we've heard from any (non-x86) arch maintainers? Do
> > > they consider this useful at all? Poke.
> >
> > Yes it is. I have my own version I've cobbled together for powerpc,
> > but this is much better.
>
> Please double check the PowerPC support matrix for correctness (if you
> haven't yet):

It looks good except for:

> rwsem-optimized: | ok | Optimized asm/rwsem.h # arch provides optimized rwsem APIs

I don't see an rwsem.h in powerpc anywhere?

And this is correct but a bit confusing:

> irq-time-acct: | ok | HAVE_IRQ_TIME_ACCOUNTING # arch supports precise IRQ time accounting

I think you and Paul agreed it's "ok" on powerpc because we have
VIRT_CPU_ACCOUNTING instead, but that's not obvious.

> > I'd like to see more description in the individual files of what the
> > feature is, and preferably some pointers to what's needed to
> > implement it.
>
> Yeah, so I tried to add a short description to the feature file
> itself, and for many of these features that single sentence is the
> only documentation we have in the kernel source ...

Yep, so that's better than what we had, and we can always improve it.

cheers