>> >> 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. I don't think I have any other selling point :) Being so early in the amount of commands we have in RATP, thought this could be a good improvement. Maybe I'm biased because I'm used to talking to mobile broadband modems, and that is how all protocols I know are defined. That said, changing this to keep the API would still be very easy, it's no big deal. -- Aleksander https://aleksander.es _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
