Hi Oleg,
Please find my response inline.
Hi Saket. I have been active in the very work you brought up. The goal I have set is to
resync the Intel branch to what is current in the upstream kernel. This has required us to
update the intel branch to handle kernel api changes in newer kernels as well as remove
api wrappers like the ones you pointed out. Currently our efforts
are covered with several tickets.
LU-3963 : Move libcfs wrappers to linux api
LU-5275 : Remove procfs technical debt
LU-5530 : Support for sysfs
LU-5443 : Use kernel timer apis
LU-4416/LU-4493: New kernel support.
LU-4423 : backport upstream kernel patches.
From what you posted about it seems LU-3963 is the best place for your
work. Also work was done for server/client splitting (LU-1330) but more work could be done
since it will be needed for the coming client/server rpm split. Here is the link about
submitting work to the Intel lustre tree:
https://wiki.hpdd.intel.com/display/PUB/Submitting+Changes
Feel free to include me in your patch inspections.
On Wed, Aug 27, 2014 at 9:36 AM, Drokin, Oleg <oleg.drokin(a)intel.com> wrote:
Hello!
I imagine lower hanging fruit would be to get rid of duplicated API in other
>functions like say linux-curproc.c has:
cfs_cap_t cfs_curproc_cap_pack(void)
{
cfs_cap_t cap;
cfs_kernel_cap_pack(current_cap(), &cap);
return cap;
}
and so on.
Yes. These duplicated APIs can easily be replaced.
I have replaced the following functions
cfs_cap_t cfs_curproc_cap_pack(void)
{
cfs_cap_t cap;
cfs_kernel_cap_pack(current_cap(), &cap);
return cap;
}
void cfs_kernel_cap_pack(kernel_cap_t kcap, cfs_cap_t *cap)
{
/* XXX lost high byte */
*cap = kcap.cap[0];
}
by a simple macro -
#define cfs_kernel_cap_pack() do { \
cfs_cap_t *cap; \
cap = current_cap().cap[0]; \
} while(0)
If you want I can send a patch for the same.
Note that some functions are more elaborate and you might want to
unwind them >more smartly or still retain as a function, just moved in a more sensical
place in the >lustre tree.
(e.g. cfs_cap_lower and cfs_cap_raise would fall under this category.
Yes. These functions are trickier to clean up but still we can make them better.
Luckily for us, the only users are in obdclass/llog*.c and in the code
that deals with >writing llogs
to disk - and that code is only used on the server, so with careful carving large
>parts of that could be dropped).
I am also aiming at demarcating the server and the client code with
#ifdef HAVE_SERVER
//server code
#else
//client code
#endif
but since I am new to the source code, I am facing difficulties in
recognizing the client and server code clearly.
With the libcfs/hash.c, I guess if there's a hash API that's
completely unused, that >one probably might be dropped too, but otherwise I imagine we
would want to >retain that file
(or possibly move it elsewhere, but there's not really a linux counterpart to that
>functionality).
I still have do a lot of study as to whether an exact linux
counterpart exists and even if the maintainers include this
libcfs/hash.c , can it be used in other drivers too.