[haiku-commits] Re: r42080 - in haiku/trunk/src/apps/debugger: . model user_interface user_interface/gui user_interface/gui/inspector_window
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 11 Jun 2011 00:46:45 +0200
Rene Gollent wrote:
> On Fri, Jun 10, 2011 at 10:29 AM, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> >> i.e. something like:
> >>
> >> class TeamMemoryBlockOwner {
> >> public:
> >> void RemoveBlock(TeamMemoryBlock* block);
> >> }
> >>
> >> ?
> >
> > Yep.
> >
>
> Thanks, will deal with it tonight. On a related note, with these
> fixes, do you want me to look at applying a similar solution to
> LocatableEntry?
Sure, if you feel motivated to do that.
> On a somewhat different tangent, do you think it would be
> worthwhile/easily feasible to allow the debug API to look up the
> protection bits on a page in the target team? The reason I ask is, the
> next item on my list once the mem inspector is usable for viewing
> target mem is to add edit support. Given that pages in the target team
> might potentially be marked read only, I'd rather know that up front
> and disable editing for that page in the inspector rather than
> allowing the user to edit and notifying later that the write failed.
> Thoughts?
Makes sense. I don't think an addition to the debug API would be the best
option. One could as well add a regular (private) function. There's already
mprotect() which sets a page's protection, the respective getter could just be
a little more generic, additionally taking a team_id parameter. E.g.:
status_t get_memory_properties(team_id teamID, const void* address, uint32*
_protected, uint32* _lock);
The syscall would look respectively.
CU, Ingo
Other related posts:
