http://oss.sgi.com/bugzilla/show_bug.cgi?id=328
tes@xxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|xfs-master@xxxxxxxxxxx |tes@xxxxxxx
------- Additional Comments From tes@xxxxxxx 2004-16-05 21:59 PDT -------
Hi Nicolas,
Thanks very much for the patch.
I see the problem that you point out.
For xfs_buf_item's we store a blf_data_map which is an array of 32bit ints
and we use xfs_buf_item_log() to add to the map. When we call xfs_contig_bits on
a 64 bit word system we have to be careful. On little endian systems the LSB of
a 32 bit word and a 64 bit word for the same data is the same but on a big
endian system they differ. So one can't just call the linux find_next_zero_bit()
function when we have 64 bit words on big endian boxes (as you mentioned).
I noticed that for xfs_next_bit() we are doing the right thing and doing our own
32 bit int code.
The xfs_contig_bits() is fairly similar to xfs_next_bit() and is largely just a
xfs_next_zero_bit() except that we want a count of all the 1s so far even if we
never find a zero (which would return -1 in the xfs_next* case).
So I compared your xfs_contig_bits() code with our existing xfs_next_bit() code
and I realised that we have a few simplifications to make which you've already
done in your code. The thing is, unlike in the kernel functions, the size
parameter in xfs code is in 32 bit ints and NOT in bits. We only do ops on size
which keep it a multiple of 32 bits and therefore some size related tests in
xfs_next_bit() can be simplified/removed. I'll make some changes for
xfs_next_bit() in a separate incident :-)
So the only thing I noticed in your code is that
while (size >= NBWORD) {
could probably be simplified to
while (size) {
and the assert removed,
since size must be a multiple of NBWORD.
Did you write this code based on xfs_next_bit() or from
somewhere else?
--Tim
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|