Date: Tue, 12 Mar 2002 11:26:38 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Andrea Campi <andrea@webcom.it> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Garance A Drosihn <drosih@rpi.edu>, Harti Brandt <brandt@fokus.gmd.de>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <Pine.NEB.3.96L.1020312112450.4664D-100000@fledge.watson.org> In-Reply-To: <20020312090810.GA8071@webcom.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Mar 2002, Andrea Campi wrote: > On Mon, Mar 11, 2002 at 07:50:58PM +0100, Poul-Henning Kamp wrote: > > > > Well, I won't promise to pick it up, but if it were working > > and there were a test-case or two, the chances of it breaking > > again would decrease. > > It's currently not working I think; I cleaned it up a couple of months > ago but I think some recent changes in API might have broken it again. > It's a matter of solving the last breakages, having it committed into > the arla -current repo, and then hopefully committing it to our own > -current. I have the kernel infrastructure ready for building it both in > the kernel and as a module. I even posted on -arch I think and the idea > met a lukewarm favor. Note that I think the code still needs to be > reviewed for the needed locks, but I was also suggested to get into the > repo first (as long as it's working) and worry about that later. The > only thing that stopped me at the time was that I definitely want to > have it committed to the arla repo first and then import on a vendor > branch, and keep it there by working with them for any and every future > patch. > > I am sure that if a guy of your ability and experience would look at it, > you could have it working in maybe half an hour. > > Setting up a client is very easy, and having Garance on board to help us > test it would be a definite plus. I'm very interested in seeing arlaxfs move into the source tree, especially if Arla people are willing to help with the inevitable cache coherency problem of it being there. Do you have in mind that this would be "contrib" code, or local code? Presumably local if we want to adapt it more to our locking model. The sooner we get it in the tree, the less work to do it later after more API sweeps go through. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020312112450.4664D-100000>