[PATCH] Cygwin: mmap: allow remapping part of an existing anonymous, mapping

Ken Brown kbrown@cornell.edu
Mon Jan 13 22:36:17 GMT 2025


On 1/13/2025 6:00 AM, Corinna Vinschen wrote:
> On Jan 11 18:43, Ken Brown wrote:
>> Another question: Adding this array to mmap_record, we have two flexible
>> arrays in the class: one for page_map and one for the protection array. My
>> understanding is that a class or struct can have only one flexible array
>> member, and it has to be at the end.  What's the best way to deal with that?
>> The only thing I can think of is to use a pointer instead of an array for
>> the protections, and then allocate memory for it separately when an
>> mmap_record is created.  Or is there a better way?
> 
> Excellent question. Right now the page map is a bitwise array, one bit
> per page.  From the top of my head I think the best way to deal with
> that is to just change the existing page_map to a uint8_t per page and
> store the mapping state in the upper bits and the protection in the
> lower bits.
> 
> Alternatively, define a bitfield, kind of like this:
> 
>    struct {
>      uint8_t	protection:3;
>      uint8_t	mapped:1;
>    } page_map[0];
Thanks.  Both of these ideas are better than what I had in mind.  By the 
way, I forgot about __PROT_ATTACH when I said we need 3 bits for the 
protection, so it's actually 4 bits.  If I decide to use your first 
suggestion, those 4 bits would have to be consecutive.  I assume it's OK 
to redefine __PROT_ATTACH to be 8 rather than 0x8000000?  Or is there 
some reason that would be bad?

Ken


More information about the Cygwin-patches mailing list