On 19.11.2021 13:50, Oleksandr Andrushchenko wrote: > On 19.11.21 14:45, Jan Beulich wrote: >> On 19.11.2021 13:13, Oleksandr Andrushchenko wrote: >>> On 19.11.21 14:05, Jan Beulich wrote: >>>> On 05.11.2021 07:56, Oleksandr Andrushchenko wrote: >>>>> From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> >>>>> >>>>> Instead of handling a single range set, that contains all the memory >>>>> regions of all the BARs and ROM, have them per BAR. >>>> Iirc Roger did indicate agreement with the spitting. May I nevertheless >>>> ask that for posterity you say a word here about the overhead, to make >>>> clear this was a conscious decision? >>> Sure, but could you please help me with that sentence to please your >>> eye? I mean that it was you seeing the overhead while I was not as >>> to implement the similar functionality as range sets do I still think we'll >>> duplicate range sets at the end of the day. >> "Note that rangesets were chosen here despite there being only up to >> <N> separate ranges in each set (typically just 1)." Albeit that's >> then still lacking a justification for the choice. Ease of >> implementation? > I guess yes. I'll put: > > "Note that rangesets were chosen here despite there being only up to > <N> separate ranges in each set (typically just 1). But rangeset per BAR > was chosen for the ease of implementation and existing code re-usability."
FTAOD please don't forget to replace the <N> - I wasn't sure if it would be 2 or 3. Also (nit) I don't think starting the 2nd sentence with "But ..." fits with the 1st sentence. Jan
