New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

investigate new "fd" field in shm extension #18

Open
BurntSushi opened this Issue Dec 28, 2013 · 1 comment

Comments

Projects
None yet
2 participants
@BurntSushi
Owner

BurntSushi commented Dec 28, 2013

A new XML element fd has showed up in the protocol description for the shm extension.

A temporary fix in commit 490ec2a ignores this field.

What is it for? (File descriptor name?)

@pjanx

This comment has been minimized.

Show comment
Hide comment
@pjanx

pjanx Aug 23, 2018

The field indicates that you are supposed to send or receive a file descriptor over the Unix socket you're connected to (so long as it's not TCP). The other side can then e.g. mmap memory on it.

Let's talk about receiving for now, which might be the more complex part.

The mechanism has only been implemented in xcb and not Xlib, as Keith Packard says. Qt has started using the API fairly recently, in commit qt/qtbase@24adaa9

Of more interest to us is the possibly sole implementation. The crux of it is slightly complicated but boils down to: each time we get to read from the socket, accept sideband file descriptors as well using the appropriate syscall and pair them to what we see in upcoming replies, or wait for more FDs again if input data went too far ahead.

This is already doable in Go. godbus needs to do this, although the implementation is messy, or there's this example code making use of a standard API.

xgb.go looks like it could be extended with relative ease.

Attaching the respective part of xcb-proto 1.13 shm.xml for context:

  <request name="AttachFd" opcode="6">
    <field type="SEG" name="shmseg" />
    <fd name="shm_fd" />
    <field type="BOOL" name="read_only" />
    <pad bytes="3" />
  </request>

  <request name="CreateSegment" opcode="7">
    <field type="SEG" name="shmseg" />
    <field type="CARD32" name="size" />
    <field type="BOOL" name="read_only" />
    <pad bytes="3" />
    <reply>
      <field type="CARD8" name="nfd" />
      <fd name="shm_fd" />
      <pad bytes="24" />
    </reply>
  </request>

pjanx commented Aug 23, 2018

The field indicates that you are supposed to send or receive a file descriptor over the Unix socket you're connected to (so long as it's not TCP). The other side can then e.g. mmap memory on it.

Let's talk about receiving for now, which might be the more complex part.

The mechanism has only been implemented in xcb and not Xlib, as Keith Packard says. Qt has started using the API fairly recently, in commit qt/qtbase@24adaa9

Of more interest to us is the possibly sole implementation. The crux of it is slightly complicated but boils down to: each time we get to read from the socket, accept sideband file descriptors as well using the appropriate syscall and pair them to what we see in upcoming replies, or wait for more FDs again if input data went too far ahead.

This is already doable in Go. godbus needs to do this, although the implementation is messy, or there's this example code making use of a standard API.

xgb.go looks like it could be extended with relative ease.

Attaching the respective part of xcb-proto 1.13 shm.xml for context:

  <request name="AttachFd" opcode="6">
    <field type="SEG" name="shmseg" />
    <fd name="shm_fd" />
    <field type="BOOL" name="read_only" />
    <pad bytes="3" />
  </request>

  <request name="CreateSegment" opcode="7">
    <field type="SEG" name="shmseg" />
    <field type="CARD32" name="size" />
    <field type="BOOL" name="read_only" />
    <pad bytes="3" />
    <reply>
      <field type="CARD8" name="nfd" />
      <fd name="shm_fd" />
      <pad bytes="24" />
    </reply>
  </request>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment