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

[Corinna Vinschen]

On Jan 13 17:36, Ken Brown wrote:
> 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?

Not at all.  The value was chosen arbitrarily.


Corinna