On 03/24/2015 05:41 AM, Boaz Harrosh wrote: > On 03/23/2015 05:19 PM, Rik van Riel wrote: >> There are two things going on here: >> >> 1) You want to keep using struct page for now, while there are >> subsystems that require it. This is perfectly legitimate. >> >> 2) Matthew and Dan are changing over some subsystems to no longer >> require struct page. This is perfectly legitimate. >> > > How is this legitimate when you need to Interface the [1] subsystems > under the [2] subsystem? A subsystem that expects pages is now not > usable by [2]. > > Today *All* the Kernel subsystems are [1] Period. That's not true. In the graphics subsystem it is very normal to mmap graphics memory without ever using a struct page. There are other callers of remap_pfn_range() too. In these cases, refcounting is done by keeping a refcount on the entire object, not on individual pages (since we have none). > How does it become > legitimate to now start *two* competing, do the same differently, abstraction, > in our kernel. We have two much diversity not to little. We are already able to refcount either the whole object, or an individual page. One issue is that not every subsystem can do the whole object refcounting, and that it would be nice to have the refcounting done by one single interface. If we want the code to be the same everywhere, we could achieve that just as well with an abstraction as with a single data structure. Maybe even something as simplistic as these, with the internals automatically taking and releasing a refcount on the proper object: get_reference(file, memory_address) put_reference(file, memory_address) -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
