Re: [Dazuko-devel] DazukoFS

[John Ogness]

address@hidden wrote:
>>Well, yes, it does work. However, it uses the d_path() function. One of
>>the advantages of DazukoFS is that we can get away from the d_path()
>>function. The problem with this function is:
>>
>>4. __d_path() would allow us to get around #2, but it is not re-entrant
>>safe and it is not exported to modules
> 
> What exactly do you mean with re-entrant safe?

d_path() is a wrapper for __d_path() that does two things: It uses the
root mount of the current process and it calls __d_path() while holding
the necessary lock "dcache_lock".

Unfortunately "dcache_lock" is a static variable within fs/dcache.c,
which means no other kernel code outside of fs/dcache.c can access this
lock. This means that a kernel module cannot safely call __d_path() (on
SMP machines) and must use the "restricted" d_path() function.

Note: I just noticed that 2.6.20 now exports dcache_lock. Interesting...


> The only remaining problem will be hot to handle removable devices and new 
> mounts in general. I don't see a completely secure solution for that with 
> stackable filesystem only approach, right?

If by "secure" you mean "automatic", you are correct. Right now we are
not aware of a way to always auto-mount DazukoFS on top of any newly
mounted filesystem. However, I am not experienced in automounters and
what types of hooks they might support.

I also believe we have a fairly good chance of getting DazukoFS into the
mainline kernel (once it is ready). This would certainly help improve
efforts for automount support.

John Ogness

-- 
Dazuko Maintainer