+1 For all these new backstores I think we need some way to allow them to only support a subset of the commands that are available in sbc.c I think that bs_rdwr.c being the most generic backend will probably always be the most "complete" one and other backends always be some steps behind in areas like support for new opcodes. For example UNMAP. Maybe this command does not make much sense at all on backends that can not punch holes. I would like to add a bitmap to the backend structure where there is one bit for each opcode and setting the bit to 0 means no-support. Then if an initiator sends that opcode, even if sbc.c has it implemented, when the backend has the corresponding bit set to 0 we will respond with ILLEGAL_OPCODE. I think this will allow us to be more correct when responding and handling backends which do not have all the opcodes. This could also spill over into the READ_SUPPORTED_OPCODES call where we could prune the list to only report those opcodes that the backend actually supports. regards ronnie sahlberg On Thu, Sep 26, 2013 at 9:40 PM, Andy Grover <agrover@xxxxxxxxxx> wrote: > On 09/26/2013 08:40 PM, Dan Mick wrote: >> >> >>> Thanks for the explanation. >>> So if there is no sheepdog library at this stage then I guess there is >>> no alternative to having a full reimplementation. >>> In that case it should not matter much whether it is built in or a >>> module. >> >> >> +1 > > > Yeah I'm also fine with built-in for now. Nice to see these new backstores > being added! > > -- Andy -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
