Re: [patch 2/2] backport of sba sg list management to ccio-dma

Grant,


Grant Grundler wrote:
> On Sun, Oct 28, 2007 at 02:45:24PM +0000, Joel Soete wrote:
> ...
>> e.g.
>> # more GetOrder-poc.c
> ...
>> give me well same results:
>> # ./GetOrder-poc
>> get_order(1) = 0 (0x0);
>> get_order_poc(1) = 0 (0x0).
> ...
> 
> Good!
> 
> ...
>> But I need to check more on a detail:
>> here is the prototype of fls():
>> static inline int fls(int x)
>>
>> so I need to be sure that the value of ((size - 1) >> (PAGE_SHIFT)) would 
>> always stand in a int (not unsigned but sign) for 32bit (iirc 
>> size_of(unsigned long)==32) and 64bit (size_of(unsigned long)==64) 
>> implementations?
> 
> Huh?
> Why do you care how (unsigned long) is handled when the function prototype
> defines the API to pass in an "int"?
> 
Because I only have a theoritical knowledge of programming :<?

> FWIW, __fls could be extended to handle unsigned long the same way
> that __ffs has been...but I don't think we needed to for anything so far.
> 
Ok, I could check if I can recover my stuff about this fls()?
(should be something like <http://lists.parisc-linux.org/pipermail/parisc-linux/2006-September/030209.html>, I will test more)

> ...
>>>> 	return (size ? fls((size - 1) >> (PAGE_SHIFT)): 0);
>>> fls is inlined already and does the same test for size.
>> Yes but here the error (well imo it's an error) came from the unsign long 
>> of (-1 >> PAGE_SHIFT) <> 0
> 
> Yeah, we'll have to make sure signed int values are handled correctly too.
> But something specific to the parisc version of get_order() can deal
> with sign bits and zero values then call __fls(unsigned long) instead
> of fls(signed int).
> 
> grant
> 
> 
Tx again,
	j.