On Tue, 15 Jun 1999, Martin von Loewis wrote:
> > Mmmm. I think it might be easier just to pull the thing apart and
> > make it pass buffer_heads around, rather than allocing and copying
> > data willy-nilly.
>
> Please no. That would break the separation of FS routines and OS
> adaptation, and thus break the command-line tools (which have no
> buffer_heads to pass around).
Martin, do you *really* need to keep the completely the same codebase for
kernel and userland? NTFS uses kmalloc() in way too many places for
absolutely no reason, as far as kernel source counts.
> Of course, if you design an interface that provides some abstraction
> above buffer_heads, and which can also be implemented in user-level
> code: go ahead.
> As for the locking problems: I think having a meta-data lock would be
> reasonable. Again, this would need an indirection so that it is no-op
> in user space.
Methink it isn't. Looks like the right thing to do is to keep first 16
inodes permanently in-core (iget() them upon ->read_super() and keep
pointers them in ntfs_super_info) and use normal ->i_sem for locking.
