Re: [RFC PATCH 00/10] ratp: new generic RATP command support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>
>> 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



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux