Tushar wrote: >> Yes. Increased number of context switches is a problem, but as I see it, >> building a custom kernel is an even bigger problem. Customers are not happy >> with that. > > Why there is multiple context switches? I will like to know more about > it.
If Dazuko returned a local path, the application would need to build the full path using the /proc system (/proc/PID/root). Retrieving this data from the /proc filesytem involves an extra context switch. At the moment, using Dazuko requires an extra switch (to userspace and back to kernelspace) for each file event. For chroot'd processes, this would require 2 extra context switches than without Dazuko. This is certainly very fast (and negligible in comparison to what a virus scanner does with the even), but I felt it was worth mentioning. > As /proc is dynamically generated, it would be great if somehow we can > manage to get the root entry in kernel space itself and return final > path to user. This way, we can keep semantics of filename field same for > all process. Please let me know what u people think about this. This sounds like a good idea, but I don't know how easy it would be (or if it is even possible). The 2.6 kernel uses a lot of "internal" locks on its structures that are not available to kernel modules (statically defined and available only for non-exported functions). This is why we require a kernel patch for __d_path() on SMP systems. I haven't looked at the code yet, but I suspect that a kernel module does not have access to the required locks needed to get this information. For Linux 2.6, loadable kernel modules are not nearly as trusted as built-in modules. John Ogness -- Dazuko Maintainer _______________________________________________ Dazuko-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dazuko-devel
