Re: [PATCH] Revert kheaders feature

[Joel Fernandes]

On Wed, Feb 05, 2020 at 04:55:39PM +0000, Olof Johansson wrote:
> On Wed, Feb 5, 2020 at 4:02 PM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote:
> >
> > On Wed, Feb 05, 2020 at 03:46:29PM +0000, Greg Kroah-Hartman wrote:
> > > Now that BPF does not need a copy of the kernel headers anymore in order
> > > to build programs, there's no real need for putting the kernel headers
> > > into a kernel module.  So drop the feature quick, before someone starts
> > > using it :)
> >
> > Temporary Nack. Adding Alexei to the thread.
> >
> > I believe at the time of this going in, the BPF's BTF feature was not fully
> > ready or able to support the usecases. Especially because BPF programs can
> > call or use macros in kernel headers as well.
> >
> > Also, now BCC project does depend on this and so does bpftrace. Have both
> > of these tools migrated to use BTF and don't need CONFIG_KHEADERS to be
> > compiled? Sorry if I lost track.
> >
> > Just last week someone was using CONFIG_KHEADERS for BPF tracing purposes at
> > Google and pinged me as well. There are several others. This would at least
> > them some amount of pain.
> >
> > I'd suggest let us discuss more before ripping it out. thanks,
> 
> 
> Greg, please use olof@xxxxxxxxx on the patch, I try to keep LKML out
> of my non-upstream inbox. :-)
> 
> 
> Alexei was part of the discussion, and from others in the same room it
> sounded like there are no users of the upstream version of this
> feature. Posting this patch is the obvious way to find out if that is
> the case.
> 
> I.e. even if there was a version of bcc that required this, it sounds

The upstream BCC currently does require it since several tools include kernel
headers and bpftrace does require it as well. I guess my point was before
ripping it out, someone needs to complete the migration of all of those tools
to BTF (if BTF can even handle all usecase) following the motto of "Don't
break userspace".

> like the BTF approach is significantly better and said users are
> hopefully moving forward to it quickly, and if they can't move
> forward, then they're likely also not going to move forward to newer
> kernels either?

I think BCC runs on a lot of upstream machines. I think the migration
strategy is a matter of opinion, one way is to take it out and cause some
pain in the hope that users/tools will migrate soon (while probably carrying
the reverted patches out of tree). Another is to migrate the tools first and
then take it out (which has its own disadvantages such as introducing even
more users of it while it is still upstream).

thanks,

 - Joel