[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Build fix
- To: "Michael C . Wu" <keichii@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: Build fix
- From: Robert Watson <rwatson@xxxxxxxxxxx>
- Date: Sun, 6 May 2001 09:42:35 -0400 (EDT)
- Cc: Tom Maher <tardis@xxxxxxxxxx>, freebsd-afs@xxxxxxxxxxx, port-freebsd@xxxxxxxxxxx
- Delivered-to: freebsd-afs@xxxxxxxxxxx
- In-reply-to: <20010426111730.A85910@xxxxxxxxxxxxxxxxxxxx>
- Sender: owner-freebsd-afs@xxxxxxxxxxx
On Thu, 26 Apr 2001, Michael C . Wu wrote:
> On Fri, Apr 20, 2001 at 06:24:43PM -0400, Robert Watson scribbled:
> | On 20 Apr 2001, Tom Maher wrote:
>
> If we ever plan on importing OpenAFS, should our development and porting
> platform be 5.0-CURRENT instead? I realize the similiarities in
> toolchains, etc. However, Since OpenAFS is technically a
> ``filesystem,'' with the precedence of NFS and Coda, we should at least
> make sure it works with our development platform.
Well, it's certainly arguable that the kernel module should work on both
4.x-STABLE and 5.0-CURRENT. I would imagine that, in general, the
userland code wouldn't care much if at all which it is running on. There
have been some VFS changes between -STABLE and -CURRENT, but the most
notable difference lies in the kernel synchronization primitives. If you
take a look at Boris's SMBFS code, you'll see he works around this by
abstracting away from {lockmgr, sxlock} to make use of a generic locking
interface. This is probably the right approach for file system modules
that are under active development and intended to work on both branches.
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@xxxxxxxxxxxxxxxxx NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-afs" in the body of the message