Re: [PATCH] perf tool: more user-friendly errors from trace

From: Ramkumar Ramachandra
Date: Fri Oct 04 2013 - 00:53:25 EST


Arnaldo Carvalho de Melo wrote:
> [acme@zoo ~]$ mount | grep debugfs
> [acme@zoo ~]$
> [acme@zoo ~]$ perf trace usleep 1
> Is debugfs mounted? Try 'sudo mount -t debugfs nodev /sys/kernel/debug'
> [acme@zoo ~]$ sudo mkdir /d
> [acme@zoo ~]$ sudo mount -t debugfs nodev /d
> [acme@zoo ~]$ mount | grep debugfs
> nodev on /d type debugfs (rw,relatime)
> [acme@zoo ~]$
> [acme@zoo ~]$ perf trace usleep 1
> Couldn't access debugfs. Try 'sudo mount -o remount,mode=755 /d'
> [acme@zoo ~]$ sudo mount -o remount,mode=755 /d

On Arch, I just had to `chmod go+rx /sys/kernel/debug`, and add an
entry to fstab so it works across reboots. Remounting by hand works
too, but it's likely that users are more familiar with simple
filesystem permissions.

> + case ENOENT:
> + fputs("Is debugfs mounted? Try 'sudo mount -t debugfs nodev /sys/kernel/debug'\n", trace->output);

Doesn't an ENOENT indicate that the kernel was not compiled with
debugfs support in the first place? Isn't it systemd's job to check
the kernel for the feature and do the mounting?

> + case EACCES:
> + fprintf(trace->output,
> + "Couldn't access debugfs. Try 'sudo mount -o remount,mode=755 %s'\n",
> + debugfs_mountpoint);

Instead of giving a specific line to execute, I'd prefer if the error
described that the current user does not have permissions to read
$debugfs in words.

Your patch splits the error into two different bits, which I like. But
I prefer the wording in my original patch: so, I'll re-work my patch
and re-submit.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/