Well, there was no ceph_options pointer in the messenger layer and no_crc flag was being passed into the messenger as an additional flag and maintained within the messenger again as bool no_crc, I inferred that it was intentional and we did not want the generic options in the messenger layer. If it is fine to have messenger point back to the ceph_options, then that’s the easiest way to do it. Also, we would have some additional option coming in with RDMA support (xio messenger) which would be very messenger specific, so having a messenger options had made sense. Regards, Chaitanya -----Original Message----- From: Ilya Dryomov [mailto:ilya.dryomov@xxxxxxxxxxx] Sent: Thursday, January 22, 2015 7:59 PM To: Chaitanya Huilgol Cc: Somnath Roy; Sage Weil; Chaitanya Huilgol; Ceph Development Subject: Re: [PATCH] ceph: rbd option listing and tcp_nodelay support On Thu, Jan 22, 2015 at 4:33 PM, Chaitanya Huilgol <Chaitanya.Huilgol@xxxxxxxxxxx> wrote: > Ok, I think for now we should first get the core feature support in, > if the changes in the messenger layer look fine, then I will generate > two patches > - messenger specific options > - tcp_nodelay support > > As a next set we can implement the krbd_default_map_options in the ceph.conf and pass it down. > > Let me know. Honestly, I don't see the point of splitting options the way you did either. There is just too much boilerplate for something as simple as couple of flags: a struct with a single field to which ceph_messenger then has a pointer, all the msgr opt macros (why?), the fact that libceph options are now split between libceph.h and messenger.h, etc. I'd just pass struct ceph_options * to ceph_messenger_init() and be done with it. Thanks, Ilya ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
