Date: Mon, 17 Sep 2001 11:36:27 +0200 From: Christoph Hellwig <hch@ns.caldera.de> To: Terry Lambert <tlambert2@mindspring.com> Cc: Dennis Berger <Dennis.Berger@nipsi.de>, freebsd-fs@FreeBSD.ORG, opengfs-devel@lists.sourceforge.net Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <20010917113627.A28298@caldera.de> In-Reply-To: <3BA5BDBC.107DC520@mindspring.com>; from tlambert2@mindspring.com on Mon, Sep 17, 2001 at 02:09:16AM -0700 References: <3BA4B507.CC70ECD4@nipsi.de> <20010916140843.A21982@xor.obsecurity.org> <3BA52C79.E1E247F5@mindspring.com> <3BA5419F.BF0C3E70@nipsi.de> <3BA555D8.D2C53387@mindspring.com> <20010917084023.A13990@caldera.de> <3BA5AF53.EE87658F@mindspring.com> <2 <3BA5BDBC.107DC520@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 17, 2001 at 02:09:16AM -0700, Terry Lambert wrote: > Christoph Hellwig wrote: > > > > We (the OpenGFS project) have spend about ten times as much time > > > > just to fix the horrible implementation bugs in GFS, not to mention# > > > > that it also has a lot of design problems. > > > > > > I'm only worried about the drivers for the weird hardware, and > > > the interoperability issues. > > > > There is no hardware driver. You just need a scsi subsystem that can > > handle 16 byte cmds if the host controller can handle it. (And of course > > a controller that actually implements this specific commands). > > This disagrees with a discussion I had off list, as to the use > and availableility of DLOCK, and the firmness of the SCSI III > standard. The GFS people are using Matt Jacob's fiberchannel > driver, and a network based distributed lock manager. DLOCK was GFS 3.x. GFS 4.x and OpenGFS use dmep. > > > preclude using it as a boot FS, or shipping a CDROM which would > > > install to it as the root FS type, by way of user selection > > > (preferred) or by default (annoying to commercial users). At least > > > I can actually use the code... > > > > The first yes, the second not. > > Tell me how I can distribute a binary, where it is impossible for > all the code to be under GPL because some of the code is under > another license, yet statically link it with GPL'ed code? I never said that you can redistribute the binary. > I _can not_ ship a CDROM which would install to it as the root FS > type. Nor can I create a FreeBSD bootloader, since reading the > kernel off the dosk would require linking ot with GFS code in the > libstand -- something I can not do, because of the license conflict > there, as well. If libstand is only two-clause BSD on not four-clause it should be ok, at least there are a lot of this mixes. But I really hate this stupid license discussions, especially on technical lists. > I can't even do it as a user selection, unless I compile the kernel > to an MFS locally -- and doing that is considered a "no no", or I > would just distribute all GPL'ed code as ANDF code (using TenDRA), > and then link it at install time, and totally igonre the GPL as an > irrelevancy. You can link it withput problem - as long as you don't redistribute the linked product. > > I didn't suggest that you use the code (once we're done with cleaning > > it up it won't be the same anyway), but implement a new kernel part, > > sharing the format and protocol with OpenGFS (and current Sistina > > GFS, but I suspect they will change their format as often as the LVM > > one). > > As you mentioned above that you write almost asleep it shouldn't be > > too difficult :) > > Do you have documentation for the layout and theory of operation, > said documentation not itself being GPL'ed, but instead, fully > public domain and/or published with perpetual rights granted for > derivative works? Currently we don't. It would be a very very good thing as we are truly open then, compared to Sistina's version. > If someone would write a fiberchannle driver, and tell me where I > can buy cheap hardware, I could probably write a GFS-like FS from > scratch; but it's not something I'm interested in taking on, if it > means that there's nothing to run it on but local disks, when I get > there (ugh!). You can use OpenGFS without dmep-capable hardware as well, there's still the IP option. Christoph -- Of course it doesn't work. We've performed a software upgrade. 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?20010917113627.A28298>