On Thu, Sep 16, 2010 at 11:19:28AM -0400, Arnd Bergmann wrote: > fs/coda: > Coda seems to have an active community, but not all of their > code is actually part of linux (pioctl!), Probably more than 99% of the code is running in userspace. And that isn't really pioctl related, a pioctl is simply an ioctl that can in a somewhat cross-platform way operate not just on files, but also on symlinks and directories because it is path based instead of fd based. These path-ioctls are there for user commands on specific objects visible in the filesystem, examining and repairing conflicts, forcing cache refresh or prefetch, accessing extended information such as which servers store a replica of the object. Some of this could move to extended attributes, other things might work without kernel involvement over a unix-domain socket, but the hard part is that our userspace code is mostly identical across several systems and such features aren't universally available. > while the last official > release is missing many of the cleanups that were don in Linux. And some of those might have broken at least mounting the Coda file system. I haven't bisected yet, but I got a report that on a recent RC kernel any attempt to start Coda caused some sort of lockup. > Just removing the BKL without the Coda community seems like a heap > of pointless work. It depends, it might get rid of that mount lockup. There shouldn't be too much shared state because the kernel module mostly just forwards requests to userspace and the BKL right now seems to be mostly used to protects access to the upcall lists and could probably without too much trouble be replaced with a single 'global' (but Coda-only) or mount-point specific mutex. I have to figure out what broke mount first though. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
