Re: [Dazuko-devel] __d_path export and SMP safeness

[John Ogness]

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