From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp1040.oracle.com ([141.146.126.69]:37655 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751923AbdAJDZi (ORCPT ); Mon, 9 Jan 2017 22:25:38 -0500 Subject: Re: [RFC] Converging userspace and kernel code To: Goldwyn Rodrigues , linux-btrfs@vger.kernel.org, Jeff Mahoney , David Sterba References: <512c15bf-3c4b-3b88-1106-a7d43386400f@suse.de> From: Anand Jain Message-ID: <1b68f099-53e8-1bc8-5ffc-2dd0b21a32ae@oracle.com> Date: Tue, 10 Jan 2017 11:28:26 +0800 MIME-Version: 1.0 In-Reply-To: <512c15bf-3c4b-3b88-1106-a7d43386400f@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: Goldwyn, Could you add a list what functionality in btrfs-progs will be using the 'core'. ? Thanks, Anand On 01/08/17 21:16, Goldwyn Rodrigues wrote: > > 1. Motivation > While fixing user space tools for btrfs-progs, I found a couple of bugs > which are already solved in kernel space but were not ported to user > space. User space is a little ignored when it comes to fixing bugs in > the core functionality. XFS developers have already performed this and > the userspace and kernel code walks in lockstep for libxfs. > > > 2. Implementation > > 2.1 Code Re-arranaging > Re-arrange the kernel code so that core functions are in a separate > directory "libbtrfs" or "core". (There is already libbtrfs_objects > keyword defined in Makefile.in, so I am not sure if we should use > libbtrfs, or perhaps just core). The core directory will contain > algorithms, function prototypes and implementations spcific to btrfs. > > Comparing the current situation, ctree.h is pretty "polluted" with > functions prototypes which do not belong there, the definition of which > are not in ctree.c. An example: functions which use struct dentry, inode > or other kernel component can be moved out of the core. Besides, > functions which could survive with btrfs_inode as opposed to inode > should be changed so. We would need new files to split the logic, such > as creating inode.c to keep all inode related code. > > 2.2 Kernel Stubs > Making the core directory a drop-in replacement will require kernel > stubs which would make some meaning in user-space. This may or may not > be included in kerncompat.h. Personally, I would prefer to move > kerncompat.h into kernel-stub linux/*.h files. The down-side is we could > have a lot of files and directories for stubs, not forgetting the ones > for trace/*.h or event asm/*.h. > > 2.3 Flag day > Flag day would be the day we move to the new directory structure. Until > then, we send the patches with the current directory structure. After > flag day, all patches must be ported to the new directory structure. We > could request developers to repost/retest patches leading up to the flag > day. > > > 3. Post converging > Checks/scripts to make sure that patches which are pushed to kernel > space will not render user space tools uncompilable. > > While these are my (and my teams) thoughts, I would like suggestions > and/or criticism to improve the idea. >