Inefficiency in access masks

[ShabbyX]

Inefficiency in access masks

[Tobski]

Hi @ShabbyX - sorry for the delay in replying - don't get much traffic over here atm!

So this was 100% a deliberate design choice. In practice, drivers are already ignoring bits that don't mean anything on the basis that they have no sane meaning, and that they also aren't required to be set. So setting a READ bit in a source mask (like your example above) should really have no effect on an implementation, barring a few old drivers from before the synchronization chapter was rewritten to be actually consistent and make some sense 😅.

That said, this library could act as an intermediate optimiser by nulling some more things out like this, right now this library is only acting (mostly) as a reference with a few obvious access types not being passed to the driver. I have a couple of outstanding things I'm consider doing as well in the same vein, so I'll consider doing this if I do those.

NB: If you wanted to help out and provide a PR you're quite welcome, but I'd rather this be handled programmatically in the function calls instead of duplicating fields in the mapping. This could be done by detecting whether the source and destination include reads or writes, and reacting accordingly - otherwise it's just a bunch of copy pasta for access types that aren't both READ and WRITE. If you wanted to look at a PR, let me know and I'll elaborate, otherwise I'll take a look over my (non-public) todo list and see what I want to do here.

[ShabbyX]

@Tobski, that makes sense. Thanks for the explanation.

I don't intend to work on this repo (or use it), though I did get inspiration from it in my own work. I just wanted to point this out, which turned out you were already aware of.