Re: [RFC] Provide in-kernel headers for making it easy to extend the kernel

[Karim Yaghmour]

On 1/23/19 11:37 PM, Daniel Colascione wrote:
> While I think there's definitely a place for eBPF as part of the
> Android performance toolkit, I think most users will end up using it
> through rich front-end performance collection and analysis tools (of
> the sort I'm working on) rather than directly as a first-line window
> into the operation of the system.

Sure, I don't disagree.

> Below this level is probably
> something like bpftrace, and below that, raw eBPF and ftrace
> manipulation. It's also worth noting that much of the time, system
> analysis is retrospection, not inspection (e.g., investigating the
> causes of rare and hard-to-reproduce bad behavior), and so iteration
> via interactive specification of eBPF programs isn't a practical path
> forward. It's still useful, even in this scenario, to be able (as part
> of higher-level tools) attach "canned" eBPF programs to the kernel to
> extract certain generally-useful bits of information, and in this
> capacity, Joel's header module would be useful.

Hmm. Not sure I agree about that. There's no reason I can't use Android 
Studio to "right-click" on a line of code or even a span of code and 
select a "trace this in detail for me" option, where "in detail" could 
mean different things depending on the code that's highlighted. Doing 
I/O calls? Then automatically measure some I/O benchmarks for that 
portion of code. Doing graphics calls? Do the same for the graphics 
stack, etc.

> > Personally I advocated a more aggressive approach with Joel in private:
> > just put the darn headers straight into the kernel image, it's the
> > *only* artifact we're sure will follow the Android device whatever
> > happens to it (like built-in ftrace).
>
> I was thinking along similar lines. Ordinarily, we make loadable
> kernel modules. What we kind of want here is a non-loadable kernel
> module --- or a non-loadable section in the kernel image proper. I'm
> not familiar with early-stage kernel loader operation: I know it's
> possible to crease discardable sections in the kernel image, but can
> we create sections that are never slurped into memory in the first
> place? If not, maybe loading and immediately discarding the header
> section is good enough.

Interesting. Maybe just append it to the image but have it not loaded 
and have a kernel parameter than enables a "/proc/kheaders" driver to 
know where the fetch the appended headers from storage at runtime. There 
would be no RAM loading whatsoever of the headers, just some sort of 
"kheaders=/dev/foobar:offset:size" parameter. If you turn the option on, 
you get a fatter kernel image size to store on permanent storage, but no 
impact on what's loaded at boot time.

> Would such a thing really do better than LZMA? LZMA already has very
> clever techniques for eliminating long-range redundancies in
> compressible text, including redundancies at the sub-byte level. I can
> certainly understand the benefit of stripping comments, since removing
> comments really does decrease the total amount of information the
> compressor has to preserve, but I'm not sure how much the encoding
> scheme you propose below would help, since it reminds me of the
> encoding scheme that LZMA would discover automatically.

I'm no compression algorithm expert. If you say LZMA would do the 
same/better than what I suggested then I have no reason to contest that. 
My goal is to see the headers as part of the kernel image that's 
distributed on devices so that they don't have to be chased around. I'm 
just trying to make it as palatable as possible.

> > Whether such craziness makes sense or is adopted or not isn't mine to
> > chart, but I certainly can't see eBPF reaching the same mass deployment
> > ftrace has within the Android ecosystem until there's a way to use it
> > without having to chase kernel headers independently of kernel images.
> > There are "too many clicks" involved and someone somewhere will drop the
> > ball if it's not glued to the kernel in some way shape or form. Any
> > solution that solves this is one I'd love to hear about.
>
> I agree. There definitely needs to be a "just collect a damn trace"
> button that works on any device, and for this button to work and
> incorporate eBPF, the system needs to be able to describe itself.

I like that: "the system needs to be able to describe itself". True.

Cheers,

--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour