Hello On Thursday, October 28, 2010 23:07:30 Julian Anastasov wrote: > > Hello, > > On Thu, 28 Oct 2010, Simon Horman wrote: > > > As it stands a little more than 256 bytes may be needed for > > pe_data (+ pe_name_length + pe_name). This could be resolved by > > shortening the maximum pe_data length. Or perhaps we could use 16 bytes for > > Option length, which should ensure its never too small. > > > > The 256 byte limit that I made for pe_data was arbitrarily chosen. > > Yes, this is a problem. > > >>> We can have a better fine tuning of options in this way. > >> > >> Yes, that is exactly my idea. I more like the name > >> "Parameter" instead of "Option", i.e. we have additional > >> parameters that can be mandatory (usually) but also can be > >> optional. For now I don't have idea for any optional > >> parameters but allocating 1 bit for this does not look > >> fatal. > > > > I'm not sure I understand the motivation for optional parameters. > > I think its important to allow for backwards compatibility. But > > I don't see that there will be multiple independent implementations > > of the synchronisation daemon in the near future. So the use-case > > isn't clear to me. > > If we want to support optional parameters they > must have some known length field, 16 bits if needed. > But if we don't want such optional parameters then > we can just use single octet for parameter type > which can imply the length of the following data. > Types that have data with variable length should provide > 1 or 2 octets after the parameter type for their length. > So, the parsing should be per-type. If one day > we need optional parameters we can just add 1 octet for > type and 2 for length before data. > > For example, ip_vs_sync_conn_options if implemented > as parameter can be coded with 1 octet for type and the > following data structure. OTOH, PE params can use 1 octet > for type, 2 for length (read with get_unaligned_be16) and > then data. OK, a minor change in length check only. For todays known types one byte is ok, since pe data willbe splitted. > > > That said, I agree that allocating 1 bit isn't a show-stopper. > > Regards > > -- > Julian Anastasov <ja@xxxxxx> Regars Hans Schillstrom <hans@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
