> I suspect that's the way to go? It'd also avoid a type called > __ceph_file_layout, which isn't particularly obvious. Good point, i'll make another pass on this, and we'll see how it looks.
I've been motivated to clean-up some of the file layout and object mapping code in the client because I've been thinking a lot about the idea of generalized mappings, that go beyond the object/stripe paradigm, and perhaps have non-uniform layouts determined programmatically on a per-file basis. There are lot of other issues...hah. > I've been using __ > throughout to mean something like "I'm already holding the relevant > lock(s)" but that's not much better (tho hopefully it's at least > pretty > consistent). Yeh, that's pretty common practice. Using _otw_ is worth looking at, but there probably isn't a really great way to solve it in the long run. Just look at the mini-summit at Japan Linux Symposium that Thomas Gleixner held for the single purpose of naming spinlock variants in the -rt patch. I've been hacking on stuff as I run across it, but do you have bug tracker or to-do lists online? -n ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ceph-devel mailing list Ceph-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ceph-devel
