John Marino <mfl-commissioner%marino.st@localhost> writes: > On 7/22/2012 21:19, Greg Troxel wrote: >> >> Indeed. In particular coda needs a kernel module. If that isn't known >> to work -- and all the MAXNAMELEN issues are trivial compared to the >> kernel module -- all of this is just noise. > > I'll see if FreeBSD's kernel module is portable (easily) to > DragonFly. It's not available now. If it's not portable or if there's > no interest, we can pull the patches as they would be pointless. If > we get coda, then I'll raise the issue upstream. > > Sound good? I wasn't fully aware of the last information there. That sounds like a good plan. For the kernel module, there has been a version in FreeBSD since the late 90s. The tricky parts are about vfs protocol changes and widths of types. I would recommend reading the history of both the FreeBSD and NetBSD kernel modules. There were a few recent fixes to the NetBSD version, but I think those may not be applicable to a FreeBSD-derived module. Also, there were two kernel protocol versions, and only one is of interest now. It's sort of on my todo list to purge the old one from NetBSD. I think there was version 4, for coda-4.x, and version 5, for 5.x and 6.x. Coda's kernel module is somewhat like FUSE. I have long thought that coda should have a fuse backend, rather than a custom kernel module. That's probably more work than porting the kernel module to DragonFly, but also of much broader utility.
Attachment:
pgpyXNikpoDBj.pgp
Description: PGP signature