On 08/24/2012 11:26 AM, Alex Elder wrote: > I keep moving simple and simplifying patches to the front of > my patch queue. This is my latest set of things that are > ready to get reviewed and committed. > > -Alex I'm about to send updates to two patches in this series, based on comments from Yehuda's review. I'm not going to re-send the entire series. Updated are patches 03 and 06. I also am still awaiting confirmation of review for patch 05 (which has not changed and I am not re-sending). -Alex > > [PATCH 01/11] rbd: handle locking inside __rbd_client_find() > This simplifies a little code. > [PATCH 02/11] rbd: don't over-allocate space for object prefix > Don't allocate the max required space for the object prefix. > This also ensures that the object prefix is either terminated > with '\0' or else is maximally-sized. > [PATCH 03/11] rbd: kill incore snap_names_len > Eliminate an unnecessary field in struct rbd_image_header. > [PATCH 04/11] rbd: more cleanup in rbd_header_from_disk() > Rearrange some code, for better logical grouping. > [PATCH 05/11] rbd: move rbd_opts to struct rbd_device > Tie rbd-specific options to the rbd_device, not the client. > [PATCH 06/11] rbd: add read_only rbd map option > [PATCH 07/11] rbd: kill notify_timeout option > These two were done together, in this order, to preserve the > argument parsing code. The first adds the ability to map an > rbd image read-only. The second eliminates the only other > rbd option, which is otherwise unused. > [PATCH 08/11] rbd: bio_chain_clone() cleanups > Simple refactoring. > [PATCH 09/11] rbd: drop needless test in rbd_rq_fn() > Trivial. > [PATCH 10/11] rbd: check for overflow in rbd_get_num_segments() > Make sure we don't exceed 64-bit maximum when adding offset > and length. > [PATCH 11/11] rbd: split up rbd_get_segment() > Refactor rbd_get_segment() into three separate functions, > which return a segment name, offset, and length. > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
