[EMAIL PROTECTED] 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 _______________________________________________ Dazuko-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dazuko-devel
