Re: Remaining BKL users, what to do

[Jan Harkes <jaharkes@cs.cmu.edu>]

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