On Thu, Dec 20, 2018 at 11:19 AM Igor Stoppa <igor.sto...@gmail.com> wrote: > > > > On 20/12/2018 20:49, Matthew Wilcox wrote: > > > I think you're causing yourself more headaches by implementing this "op" > > function. > > I probably misinterpreted the initial criticism on my first patchset, > about duplication. Somehow, I'm still thinking to the endgame of having > higher-level functions, like list management. > > > Here's some generic code: > > thank you, I have one question, below > > > void *wr_memcpy(void *dst, void *src, unsigned int len) > > { > > wr_state_t wr_state; > > void *wr_poking_addr = __wr_addr(dst); > > > > local_irq_disable(); > > wr_enable(&wr_state); > > __wr_memcpy(wr_poking_addr, src, len); > > Is __wraddr() invoked inside wm_memcpy() instead of being invoked > privately within __wr_memcpy() because the code is generic, or is there > some other reason? > > > wr_disable(&wr_state); > > local_irq_enable(); > > > > return dst; > > } > > > > Now, x86 can define appropriate macros and functions to use the temporary_mm > > functionality, and other architectures can do what makes sense to them. > >
I suspect that most architectures will want to do this exactly like x86, though, but sure, it could be restructured like this. On x86, I *think* that __wr_memcpy() will want to special-case len == 1, 2, 4, and (on 64-bit) 8 byte writes to keep them atomic. i'm guessing this is the same on most or all architectures. > > -- > igor