On Tue, Feb 06, 2018 at 05:43:40PM +0100, Aleksander Morgado wrote: > >> > >> The first patches (1-5) break the current RATP API, by introducing > >> the concept of requests, responses and indications: > >> * Requests sent to one endpoint are expected to be replied with > >> a response by the peer endpoint. > >> * Indications are messages sent from one endpoint to another which > >> are not expected to be replied. > > > > I do not see why we have to break the RATP API. I mean currently we > > have BB_RATP_TYPE_COMMAND and BB_RATP_TYPE_COMMAND_RETURN which you > > convert to .type = BB_RATP_TYPE_COMMAND, .flags = 0 | RESPONSE. > > > > I see that using flags looks somewhat nicer, but besides of that, > > what is your selling point to break the API? > > > > Well, it was just easier to say "if I send a request of type X, I > expect back a response of the same type X". It avoids the need of > having to define which command id is expected as response for which > command id request. Well right now the lowest bit the type field can serve this purpose, i.e. "if I send a request of type X, I expect back a response type X + 1" Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
