Date: Sun, 16 Sep 2001 18:46:00 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Dennis Berger <Dennis.Berger@nipsi.de> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <3BA555D8.D2C53387@mindspring.com> References: <3BA4B507.CC70ECD4@nipsi.de> <20010916140843.A21982@xor.obsecurity.org> <3BA52C79.E1E247F5@mindspring.com> <3BA5419F.BF0C3E70@nipsi.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Dennis Berger wrote: > > Then we maybe give the guys at sistina some support, cause they > hold back the GFS-project for freebsd. > A Projectleader told me if there will be more demand, they bump > it to higher priority. > > GFS filesystem refer http://www.sistina.com I already provided them with patches against their top level source tree which made all of the user space tools and utilities compile on FreeBSD. It too me all of about 2 hours to do all of them. They also informed me that one of their engineers has FreeBSD support code for some of the kernel parts, but has not yet committed it to their tree. My bigest problem with it right now is license, since a GPL means that FreeBSD could not use it as a boot FS, which makes the code useless to me. They have indicated that they are willing to work with the license, but there are still some problems with regard to contributions by third parties made under the license under which they distribute the Linux version: either those contributions will need to be ripped out and redone, or their authors will need to assign rights to Sistina. The kernel space stuff is more complicated; I haven't had experience with the shared hardware interfaces they use (I have had experience with similar interfaces in AIX, though), nor do I have the equipment available to do a driver for them using the Linux driver as a reference implementation; I would want the documentation, anyway, since I would be wary of the end result being GPL encumbered. I estimate from looking at the Linux driver that this would take no more than 3 days worth of work (24 man hours) to get done, for someone with experience. The FS implementation itself is rather trivial, if you know what you are doing, and have knowledge of the internals of the system you are doing the work on. What FreeBSD has done with the VOP_ABORTOP code (removed it) throws a wrench into things, but it is not a serious obstacle. Really, the GFS stuff wants someone to write media drivers with range locking entry points before the rest of the code can progress. If someone wants to tackle the drivers for the oddball hardware, and will do interoperability testing with their Linux version hitting the same storage at the same time, as long as it can be put on a floppy or other removable medium, I can do the FS itself after that (I'm not interested in using GFS on local hard drives for my own purposes, so unless there is a shared device, I don't care about it). But realize, I will NOT be developing in -current, but on the 4.x branch instead, if I do this, and the issue of license must be addressed first. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA555D8.D2C53387>