On Mon, Aug 11, 2014 at 09:44:47PM -0400, Oleg Drokin wrote: > > On Aug 9, 2014, at 11:47 AM, Greg Kroah-Hartman wrote: > > > On Sat, Aug 09, 2014 at 10:34:36AM -0400, Oleg Drokin wrote: > >> > >>> Because maybe these stats preceed the introduction of perf and other > >>> tracing/debug tools? I don't know, it's really low down on the list of > >>> reasons why lustre can't be merged out of staging at the moment, you all > >>> have much bigger issues to address first. > >> > >> I wonder what is the prioritized list you have in mind? > > > > Do I really have to spell out what is wrong with that codebase that > > needs to be fixed up? It took me 50+ patches for 3.17-rc1 to just fix > > up a _portion_ of the include file mess that is in there. Now is the > > first time the code actually _builds_ properly in the kernel tree (i.e. > > no magic header file include path modifications in Makefiles preventing > > individual files from being built correctly.) > > Well, last time we discussed this topic, you said that moving most of lustre > proc files > into sysfs and other suitable venues is what prevents moving lustre out of the > staging tree under fs/
Yes, that's one of the big things, but the structure of the code itself still needs lots of work. You have wrapper functions and defines that are not needed. You have version-specific checks and still a quite complex and unnecessary include directory structure. > There well might be include mess, but this is the first time I hear about it, > and I have not seen > any build breakage or other obviously broken behavior. The build breakage came about in a thread on this mailing list when we had a tool that could build an individual .o file, which I found to break on all of the lustre files due to the odd way you were redefining the include search path of the .c files. I unwound all of that to use direct paths and now things build properly. But even then, there are way too many .h files and nested mess that is not needed and is the result of trying to get this code to build on other platforms a long time ago. > I am sure there are more things too, that's why I am asking. > We are trying to deal with stuff we know about, but it's a bit harder > to deal with the stuff we don't know about that does not manifest > itself in some clear way. Try getting rid of the typedefs and wrapper functions and #defines for function names and coding style issues. That would be a great first step and would then expose what really is left to do. Right now, it's just to hard to see the real issues. thanks, greg k-h _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
