Tikka, Sami wrote: > There is a way to get the address of the __d_path function even if it is not > exported: > > a) You can search for it, just like dazuko searches for sys_call_table in > Linux 2.4 if sys_call_table is not exported. > > b) User or some script can look up the __d_path address from System.map file > and pass it in as a module command line parameter or pass it to the driver > using the API.
My problem with these approaches is that they are hacking the kernel to get information that is not meant to be "public". Although this may work for most users, it is something that kernel developers (and myself) frown upon. It is clear that the developers of Linux 2.6 do not want people doing this. So we shouldn't do it. In my opinion we should do one of the following: a) Pressure the Linux developers to export __d_path() by default. b) Pressure the Linux developers to export __d_path() and the system call table by default. c) Remove our dependancy on __d_path() and the system call table and base Dazuko on API's that are public to kernel modules. My preference is "c" and that is what DazukoFS will be. Until then I am satisfied with requiring people to patch their Linux 2.6 SMP kernels or possibly offering a userspace workaround based on the /proc system. But I am not interested in investing time to hack into the Linux 2.6 kernel when that time could be better spent on developing DazukoFS. However, if people are willing to send in patches that capture the system call table and/or __d_path(), then I would be willing to add the patches as non-default options for Dazuko. (The options could be activated dynamically as module parameters or statically as configure options.) John Ogness -- Dazuko Maintainer _______________________________________________ Dazuko-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dazuko-devel
