David Howells <[EMAIL PROTECTED]> wrote: > > > Hi Linus, > > I'd like to improve mmap() support on !MMU still further by overloading struct > backing_dev_info::memory_backed to hold flags describing what the backing > device is capable of with respect to direct memory access.
->memory_backed is already overloaded in various awkward ways. It would be good to fix that up first, then add enhancements in a later patch. Furthermore I'd suggest that we remove ->memory_backed and simply add a bunch of new booleans to backing_dev_info rather than futzing with bitflags. Those booleans could be bitfields, of course. And those fields should refer to device capabilities and not to device characteristics: "what it can do" rather than "what it is". So "contributes to dirty memory" and "needs writeback" are good and "is a ram disk thingy" is bad. So in 2.6.11 as-is, we have: bdi->dirty_memory_acct Contributes to dirty memory accounting bdi->needs_writeback Needs writeback > (*) If bdi->memory_backed is 0, then the backing device is not accessible as > memory. Not sure what this means. > (*) If the bdi->memory_backed is non-zero, then it's a bit mask of the > following: > > #define BDI_NO_WRITEBACK 0x00000001 Invert the sense of this, use ->needs_writeback > #define BDI_MEMORY_BACKED 0x00000001 Lose this. > #define BDI_CAN_MAP_DIRECT 0x00000002 bdi->can_map_direct > #define BDI_CAN_MAP_COPY 0x00000004 bdi->can_map_copy > #define BDI_CAN_READ_MAP VM_MAYREAD > #define BDI_CAN_WRITE_MAP VM_MAYWRITE > #define BDI_CAN_EXEC_MAP VM_MAYEXEC A separate field in backing_dev_info? That `membacked' stuff in the !NOMMU implementation of do_mmap_pgoff() looks like it could benefit from some rework as a result of the above as well. It all looks rather inferential. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
