Re: Tools type sub directories


Brendan Gregg
 



On Sun, Feb 14, 2016 at 4:13 AM, allan mcaleavy via iovisor-dev <iovisor-dev@...> wrote:
Hello

As the amount of tools start to grow should we be looking to create subdirs per tool type to make it easier for other users? Looking at what we have I would categorise the tools as follows. 

Disk  biolatency.py biosnoop.py biotop.py bitesize.py ext4dist.py ext4slower.py mdflush.py
Net   gethostlatency.py opensnoop.py tcpaccept.py tcpconnect.py 
Cpu  hardirqs.py offcputime.py offwaketime.py runqlat.py softirqs.py wakeuptime.py
FS  dcsnoop.py dcstat.py statsnoop.py vfscount.py vfsstat.py xfsdist.py xfsslower.py
File   filelife.py fileslower.py filetop.py 
Memory  cachestat.py memleak.py  oomkill.py 
User  bashreadline.py pidpersec.py
Kernel / Tracing argdist.py execsnoop.py funccount.py funclatency.py killsnoop.py stackcount.py stacksnoop.py

Not quite there yet, but another ten tools or so and it's going to get onerous to pick through a long listing. I'll take a swing at this myself -- I've already had directories in mind for these (as with other toolkits). And as with other toolkits, I've found it handy to have a "bin" directory of symlinks, where one can go for grepping every script.

Brendan

 
However some tools such as pidpersec / execsnoop / memleak etc could live in a tracing context as well. Any thoughts on this or is everyone happy with the current setup? 


Al


On 12 Feb 2016, at 18:41, Brendan Gregg <brendan.d.gregg@...> wrote:



On Fri, Feb 12, 2016 at 10:13 AM, Allan McAleavy <allan.mcaleavy@...> wrote:
Hi Folks,

Has there been a consensus on the way forward with the subdir under tools?

Yes, lets have tools/old, to keep it simple.
 
I have updated biosnoop and bashreadline to use make use of bpf_perf_event_output and was looking to create a PR.

Great! I've been using bpf_perf_event_output() too (see my PR for ext4slower/xfslower), and had a few nits I need to file tickets on (I labeled some things in the code as "workaround", like it not liking u32's in the data_t). So if you ran into similar issues, you weren't alone.

Should I include a move of the current tools to a subdir. If moving I would look to update each of the appropriate man pages with additional info under see also or stability section along the lines of "For some older kernel revisions bpf_perf_event_output may be unavailable, please check for this tool in tools/xyz_dir/"

Sounds good. Just put the tool into tools/old, and add "This makes use of a Linux 4.5 feature (bpf_perf_event_output()); for kernels older than 4.5, see the version under tools/old, which uses an older mechanism."

Brendan


Thanks
Allan 

On Thu, Feb 11, 2016 at 9:12 AM, Alexei Starovoitov via iovisor-dev <iovisor-dev@...> wrote:
makes sense to me.
may be new subdir under tools/ ?
Since we have few links on the web pointing to github/iovisor/bcc/tools/

On Thu, Feb 11, 2016 at 2:53 AM, Brendan Gregg via iovisor-dev
<iovisor-dev@...> wrote:
> I'm considering creating a directory in bcc called /oldtools, for some older
> versions that work on the 4.4 kernel.
>
> With bpf_perf_event_output() in 4.5, there are many tools that I (or
> someone) should change to ditch bpf_trace_printk() and use
> bpf_perf_event_output() instead, which is more efficient and allows
> multi-user access. Great!
>
> However...
>
> Ubuntu 16.04 LTS (Xenial Xerus) will be out soon, and likely on the 4.4
> kernel. Ubuntu is not the only distribution out there, but a widely used
> one, including by Netflix. And, given this is an LTS release, I'd expect us
> to see it in use for a year or more. That gives me hesitation to break these
> tools for a wide audience, especially one who may be experiencing their
> first impression of bcc & eBPF.
>
> So I'm considering putting some older versions of tools (like execsnoop,
> opensnoop) in a temporary /oldtools directory, as I bpf_perf_event_output()
> all the things. In the distant future, we can delete /oldtools. Sound ok?
>
> Brendan
>
>
> _______________________________________________
> iovisor-dev mailing list
> iovisor-dev@...
> https://lists.iovisor.org/mailman/listinfo/iovisor-dev
>
_______________________________________________
iovisor-dev mailing list
iovisor-dev@...
https://lists.iovisor.org/mailman/listinfo/iovisor-dev




_______________________________________________
iovisor-dev mailing list
iovisor-dev@...
https://lists.iovisor.org/mailman/listinfo/iovisor-dev


Join iovisor-dev@lists.iovisor.org to automatically receive all group messages.