On Tue, Oct 29, 2002 at 07:43:35PM -0500, Luben Tuikov wrote:
> a ? a : b; <==> a ? : b;
It's a non-standard extension, and IMHO not a very good idea.
If your expression is long enough that you'd need it you
should be using explicit if-statements anyway.
> I consider the md code to be a correct implementation. Please
> see the code which I refered to in the original message.
The 2.4 MD code isn't exactly a good reference to copy from :)
2.5 md code is a lot better, but that one deals only with bios,
not buffer_heads.
> If the buffer should be written out, the dirty bit should be turned on.
> This makes sense anywhich way you look at it and think about it.
> This makes sense from 1. the code I've seen in the kernel (md)
> and from 2. logical point of view and from 3. my old OS course textbook
> (``the dinosaur book'').
It makes sense if you let the VM control the write out, but pagebuf
does the writeout explicit and the bit doesn't matter at all.
> Regarding BH_Uptodate: as you can see in the rest of the kernel,
> this bit is toggled when io is completed, from the callback function.
> Thus, it would make sense to turn it off, until the io has
> completed and then let the callback function set it to the proper value.
Look at fs/buffer.c - usually we set it before submitting and clear
it if the I/O failed. And yes, this is confusing when you look
at it.
> IOW, I want to ensure that any stacking driver, would get the proper
> idea if they _were_ to check BH_Uptodate and BH_Dirty. I don't want to
> be getting no IO just because someone decided to check BH_Uptodate
> or BH_Dirty and returned the bh without actual IO. That is, I want to
> cover the contingencies.
Drivers should never ever look at BH_Dirty. Forstunately the I/O
containers and buffer_heads are completly separate in 2.5 to avoid
such mess.
> Yes, I'd like that very much. Please tell me/point to the way _you_
> guys do your testing. We'd like to try it here, other than our tests.
the xfs CVS repo has a cmd/xfstest subdir, that's the XFS-specific
test suite, we also run the linuxtestproject (ltp) and many of the
tools from Andrew Mortons ext3 suite (see sf.net/projects/gkernel/)
over it.
|