[Lustre-devel] [wc-discuss] Important changes to libcfs primitives usage.

Alexey Lyahkov alexey_lyashkov at xyratex.com
Wed Dec 19 10:55:05 PST 2012


If you don't make a research before create a patches - why you create it?
why we need to kill current code? just for put in kernel mainline?
That is very bad idea before you will create a plan - how stable branches will supported.
because stable branch need to support older kernel and i don't like a OFED way - because that is way to introduce a strange errors.
because isn't all functions may be simulated via old API, as example a deadlock with SLES10 kernel and external OFED due bug in OFED backports.


On Dec 19, 2012, at 19:06, Liu, Xuezhao wrote:

> "Nice idea, what about conflicts with names between linux and freebsd?
> both have a atomic but with different arguments atomic_set, atomic_add as example."
> 
> For atomic_xxx in freebsd, we may refer the ofed solution. It defines atomic operations in "sys/ofed/include/asm/atomic.h".
> For ofed, there are also some other header files to provide similar semantics of linux primitives.
> 
> "did you research before make that patch to be sure no conflicts exist?"
> 
> I made those initial cleanup patches, I did worry the possible conflicts as you said.
> But I think the hard-to-resolve confliction cases should be very rare, we can deal with it case by case(the possible spin_lock_free for example as previous email).




> 
> Thanks,
> Xuezhao
> 
> On Dec 17, 2012, at 22:34, Andreas Dilger wrote:
> 
>> On 2012-12-17, at 10:09 AM, John Hammond wrote:
>>> On 12/05/2012 07:54 AM, Oleg Drokin wrote:
>>>>  I just landed first patch of the series to reduce usage of our libcfs_ wrappers for kernel primitives like libcfs_spin_lock/unlock...
>>>>  You can see actual change here: 
>>>> http://review.whamcloud.com/#change,2829
>>>> 
>>>>  It's highly likely that plenty of patches will be affected. To make our job easier, there is a
>>>>  build/libcfs_cleanup.sed script included, you can run it on all your .c and .h files to make necessary replacements:
>>>>  sed -i -f build/libcfs_cleanup.sed3  `find . -name "*.h" -or -name 
>>>> "*.c"`
>>>> 
>>>>  Please be also advised that there are more changes like this are coming (timeline is not very clear ATM, we might be able to wait with the rest until
>>>>  after feature freeze) and the sed script will be updated accordingly.
>>> 
>>> I have been wondering about wrappers and typedefs not affected by this change, for example cfs_get_cpu(), cfs_atomic_read() and cfs_proc_dir_entry_t.  In new code and patches should we use the cfs names or their Linux equivalents, get_cpu(), atomic_read(), and struct proc_dir_entry?
>> 
>> Ideally, new patches would use the Linux primitives.  However, if they are in client-side code that is compiled for liblustre, then the liblustre builds would fail until the wrappers are renamed to their Linux equivalents (i.e. removing "cfs_" prefix).
>> 
>> For server-side code and/or llite it should be fine to use the native Linux functions.
>> 
>> Cheers, Andreas
>> --
>> Andreas Dilger                       Whamcloud, Inc.
>> Principal Lustre Engineer            http://www.whamcloud.com/
>> 
>> 
>> 
>> 
> 
> ----------------------------------------------
> Alexey Lyahkov
> alexey_lyashkov at xyratex.com
> 
> 
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel
> 

----------------------------------------------
Alexey Lyahkov
alexey_lyashkov at xyratex.com





More information about the lustre-devel mailing list