On Tue, Apr 16, 2019 at 04:22:40PM +0200, Greg Kroah-Hartman wrote: > On Tue, Apr 16, 2019 at 09:45:09AM -0400, Steven Rostedt wrote: > > On Tue, 16 Apr 2019 09:32:37 -0400 > > Karim Yaghmour <karim.yaghmour@xxxxxxxxxxx> wrote: > > > > > >>> Then we should perhaps make a new file system call tarballs ;-) > > > >>> > > > >>> /sys/kernel/tarballs/ > > > >>> > > > >>> and place everything there. That way it removes it from /proc (which is > > > >>> the worse place for that) and also makes it something other than debug. > > > >>> That's what I did for tracefs. > > > >> > > > >> As horrible as that suggestion is, it does kind of make sense :) > > > >> > > > >> We can't put this in debugfs as that's only for debugging and systems > > > >> should never have that mounted for normal operations (users want to > > > >> build ebpf programs), and /proc really should be for processes but that > > > >> horse is long left the barn. > > > >> > > > >> But, I'm willing to consider putting this either in a system-fs-like > > > >> filesystem, or just in sysfs itself, we do have /sys/kernel/ to play > > > >> around in if the main objection is that we should not be cluttering up > > > >> /proc with stuff like this. > > > >> > > > > > > > > I am ok with the suggestion of /sys/kernel for the archive. That also seems > > > > to fit well with the idea that the headers are kernel related and probably > > > > belong here more strictly speaking, than /proc. > > > > > > This makes sense. And if it alleviates concerns regarding extending > > > /proc ABIs then might as well switch to this. > > > > > > Olof, what do you think of this? > > > > BTW, the name "tarballs" was kind of a joke. Probably should come up > > with a better name. Although, I'm fine with tarballsfs ;-) > > No need to have this be a separate filesystem, we can use a binary sysfs > file in /sys/kernel/ for this as the kernel is not doing any "parsing" > of the data, it is just dumping it out to userspace. What folks keep saying that an fs of header files is easier to use than tarball from bcc and cleaner from architectural pov. That's not the case. >From bcc side I'd rather have a single precompiled headers blob that I can feed into clang and improve bpf program compilation time. Having a set of headers is a step to generate such .pch file, but once generated the headers can be removed from fs and kheaders module unloaded. The sequence is: bcc checks standard /lib/module location, if not there loads kheader mod, extracts into known location, and unloads. The extraced headers are in plain fs cache and will be evicted from memory when bcc is done compiling progs. imo much cleaner than kernel maintaining headers-fs and wasting memory. Where kheaders.tar.xz is placed doesn't really matter. /proc or /sys/kernel makes no real difference.
