Re: Improving mmap() support for !MMU further

[Andrew Morton]

David Howells <dhowells@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/