On Mon, 2021-08-23 at 11:01 +0530, Venky Shankar wrote: > On Mon, Aug 23, 2021 at 10:15 AM Venky Shankar <vshankar@xxxxxxxxxx> wrote: > > > > On Sat, Aug 21, 2021 at 7:23 AM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote: > > > > > > On Wed, Aug 18, 2021 at 2:01 AM Venky Shankar <vshankar@xxxxxxxxxx> wrote: > > > > > > > > [...] > > > > > > Is "debugfs" the right place for this? I do wonder if that can be > > > dropped/disabled via some obscure kernel config? > > > > The primary use for this (v2 syntax entry) is for catching bugs in v2 > > mount syntax implementation which sounds more like a form of > > "debugging". Sysfs represents the whole device model as seen from the > > kernel. > > So, Jeff in another thread suggested that we make these debugfs > entries generic (client_features). In that case, I'm ok with having > these in sysfs. > I think debugfs is fine for this. This is mainly for teuthology, and in that case we'll have debugfs available. One of the reasons to use debugfs here is that stuff in there is specifically _not_ considered part of the kernel's ABI, so we can more easily make changes to it in the future w/o worrying as much about backward compatibility. > > > > And, sysfs is optional too (CONFIG_SYSFS). > > > > > > > > Also "debugX" doesn't sound like the proper place for a feature flag > > > of the kernel. I just did a quick check on my system and I do see: > > > > > > $ ls /sys/fs/ext4/features > > > batched_discard casefold encryption fast_commit lazy_itable_init > > > meta_bg_resize metadata_csum_seed test_dummy_encryption_v2 verity > > > > > > Perhaps we need something similar for fs/ceph? > > > > > > -- > > > Patrick Donnelly, Ph.D. > > > He / Him / His > > > Principal Software Engineer > > > Red Hat Sunnyvale, CA > > > GPG: 19F28A586F808C2402351B93C3301A3E258DD79D > > > > > > > > > -- > > Cheers, > > Venky > > > -- Jeff Layton <jlayton@xxxxxxxxxx>
