On Wed, Aug 07, 2019 at 04:29:45PM +0800, Anand Jain wrote:
> On 7/8/19 12:46 AM, David Sterba wrote:
> > On Tue, Aug 06, 2019 at 11:17:09PM +0800, Anand Jain wrote:
> >> On 7/31/19 1:10 AM, David Sterba wrote:
> >>> Export the potential debugging data in the per-filesystem directories we
> >>> already have, so we can drop debugfs. The new directories depend on
> >>> CONFIG_BTRFS_DEBUG so they're not affecting normal builds.
> >>>
> >>> David Sterba (2):
> >>>     btrfs: sysfs: add debugging exports
> >>>     btrfs: delete debugfs code
> >>>
> >>>    fs/btrfs/sysfs.c | 68 +++++++++++++++++++++++-------------------------
> >>>    fs/btrfs/sysfs.h |  5 ----
> >>>    2 files changed, 32 insertions(+), 41 deletions(-)
> >>>
> >>
> >> For 2/2:
> >>    Reviewed-by: Anand Jain <anand.j...@oracle.com>
> >>
> >> For 1/2:
> >>    IMO it would be better to delay this until we really have a debug hook
> >>    exposed at the sysfs.
> > 
> > Sorry, I don't understand what you mean.
> > 
> 
>   I notice that /sysfs/fs/btrfs/<debug>|<fsid/debug> is dummy as of now,
>   IMO its better to add this (1/2) patch along with the some actual trace
>   which is needed.

Yes it is empty for now, ready for use, like was the previous debugfs.

I don't want to delay removing the debugfs code further and not
providing a replacement does not sound as a good option, the patch would
be lost in the mailinglist.

>   Potentially either dtrace/bfp probes will be better
>   runtime debugging approach.

That's orthogonal, the sysfs is for exporting data or triggering some
action by writing to the files. The file based approach is simple to use
without external tools like bpf or even 3rd party patchsets like dtrace.

Reply via email to