On Mon, Apr 20, 2020 at 03:57:48PM +0200, Emanuele Giuseppe Esposito wrote: > > > On 4/14/20 2:56 PM, Greg Kroah-Hartman wrote: > > On Tue, Apr 14, 2020 at 02:43:00PM +0200, Emanuele Giuseppe Esposito wrote: > > > A bunch of code is duplicated between debugfs and tracefs, unify it to the > > > simplefs library. > > > > > > The code is very similar, except that dentry and inode creation are unified > > > into a single function (unlike start_creating in debugfs and tracefs, which > > > only takes care of dentries). This adds an output parameter to the creation > > > functions, but pushes all error recovery into fs/simplefs.c. > > > > > > Signed-off-by: Emanuele Giuseppe Esposito <eesposit@xxxxxxxxxx> > > > --- > > > fs/simplefs.c | 150 +++++++++++++++++++++++++++++++++++++++ > > > include/linux/simplefs.h | 19 +++++ > > > 2 files changed, 169 insertions(+) > > > > What's wrong with libfs, isn't that supposed to be for these types of > > "common" filesystem interactions? > > > > Why create a whole "new" fs for this? > > I assume you meant a new file. These new functions are used only by a few > filesystems, and I didn't want to include them in vmlinux unconditionally, > so I introduced simplefs.c and CONFIG_SIMPLEFS instead of extending libfs.c. > In this way only fs that need this code like debugfs and tracefs will load > it. Nothing "loads it", why not just make these libfs functions instead? As the difference between the two is not obvious at all, please don't make things confusing. thanks, greg k-h _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
