You are correct, I tried to put all the error handling code in separate layer, but if there is no need to print error for each system call then it does not make sense to integrate this path.
One of the userspace project on https://btrfs.wiki.kernel.org/index.php/Project_ideas#Userspace_tools_project stats that :"show meaning of various error codes, eg. for the incompatibility bits". So I thought it will be useful to have uniform error handling where it can print the error and its cause at one place and avoid the code repetition, looks like it was not the right approach. Is it possible for you to guide to implement error handling appropriately ? I would really like to work on btrfs userspace projects. Regards, Chaitanya On Tue, Oct 28, 2014 at 7:40 AM, David Sterba <dste...@suse.cz> wrote: > Hi, > > without any explanation I can only speculate what's the purpose of this > patch. I can see it hides the basic syscalls to wrappers and prints > messages in case of an error value. > > Currently, the error codes are mostly handled and the error messages are > printed as needed, we don't want to see all of them or not exactly at > the time the error happens. > > I don't see any reason why the indirection layer is needed, the bare > syscalls are usually enough. More complexity can be hidden to wrappers > like open_file_or_dir. > > The code that's shared with kernel should stick to the kernel naming and > generic functions, for that there's kerncompat.h . The userspace code > shares the CodingStyle from kernel, but obviously has to use the > userspace API so not every function starts with btrfs_ prefix etc. > > d. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
