[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haiku-bugs
Subject:    [haiku-bugs] Re: [Haiku] #12916: [Debugger] Handle retrieving image paths for chrooted teams
From:       "Haiku" <trac () haiku-os ! org>
Date:       2020-10-22 11:12:31
Message-ID: 060.6216d63e64a89a2e894c1810d2889a0c () haiku-os ! org
[Download RAW message or body]

--===============2432535285028542137==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

#12916: [Debugger] Handle retrieving image paths for chrooted teams
------------------------------------+----------------------------
  Reporter:  anevilyak              |      Owner:  anevilyak
      Type:  bug                    |     Status:  new
  Priority:  normal                 |  Milestone:  Unscheduled
 Component:  Applications/Debugger  |    Version:  R1/Development
Resolution:                         |   Keywords:
Blocked By:                         |   Blocking:
  Platform:  All                    |
------------------------------------+----------------------------
Comment (by korli):

 image_info->name is filled up by the runtime_loader, which runs in the
 io_context of the current team. Switching a path to the io_context of the
 team which does the syscall can be expensive:
 * resolve image->name to a vnode in io_context of team image
 (path_to_vnode),
 * then resolve the vnode in io_context of another team (vnode_to_path).

 I would favor another approach, that is register_image() could for
 chrooted images adjust the name to the kernel io context (imply that the
 notifications and get_next_image_info() are  correct for non-chrooted
 processes). A chrooted get_next_image_info() call could check the
 io_context root to filter the absolute path (especially for paths out of
 the chroot).
-- =

Ticket URL: <https://dev.haiku-os.org/ticket/12916#comment:1>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.
--===============2432535285028542137==--

[prev in list] [next in list] [prev in thread] [next in thread]