| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
Stan you probably should have made this a new post rather than a reply. I would first off like to say I agree with you whole heartedly that this needs to be done. On Wednesday 02 July 2003 02:51 am, Stanley Wang wrote: > Proposal for reorganizing source tree > > For historical reasons the architecture of OpenGFS source tree consists > of two layers: > > > Top layer -- VFS to GFS interface > > Each OS (or even major OS release) gets its own directory of code. > > One (big) directory of common code. > > > Bottom Layer -- GFS to bufcache/memory/etc... > > An include file and library of abstractions that GFS uses. > > > Although it works well now, we could improve it according to our current > requirement: > > 1. Since the only OS that OpenGFS supports now is Linux (no further > plan for porting work against other OS), we could combine the > common codes and architecture dependent codes into one directory > â "ogfs". And place it into the vanilla linux kernel source > tree. we talked about this before, and (I think) decided it would be better to combine all the code like you say, and use #if's like so: #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0) > > 2. We should own both 2.4 and 2.5/2.6 kernel tree, each of them > contains the corresponding ogfs codes. The 2.5/2.6 source tree > should be the active development tree. All changes in 2.5/2.6 > tree should be back ported to 2.4 tree periodically. And we > should maintain the third source tree for all the utilities and > docs. As I said before, I think we were going to try to just have one fs src tree, and one utils tree. OpenGFS has a lot of work to be done before it's known as a truly scalable and stable fs, and having do those changes to 2 different src trees would be a pain. Although your idea does have merit once we get the fs code stabilized. > > 3. For the sake of maintaining source tree more easily, we could > move from CVS to BK. Creating a project for OpenGFS @bkbits > (http://www.bitkeeper.com/Hosted.Creating.html) is quite easy. > It would also make the OpenGFS more easily to be adopted by the > mainstream linux kernel. hmm, I don't know about this. I personally have a problem with the bk license and owner. That would make it hard to for me to continue contributing to OpenGFS (which arguably hasn't been much). > > > > The reorganzing would benifit both the develop and maintain work. It > will simplify the codes and make the building work independent on the > current running kernel. And we could make full use of all Linux's > advanced features. > > Last of all, the reorganizing work is not a trivial thing. > We need a good schedule for achieving it. Have any ideas/rough schedule of how this would be done. Maybe you could put together a roadmap of sorts. Just with weeks from the start date, and then maybe we can plan on a start date. > > > Best Regards, > Stan -- OpenGFS -- http://opengfs.sourceforge.net Home -- http://www.brianandsara.net ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ Opengfs-devel mailing list Opengfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opengfs-devel