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
