3 ms·

The point is that writing to a file is basically passing a message to the kernel. Writing to a framebuffer is writing straight into memory.

by theoh 8y ago

nly 8y ago
So mmap() the file?
- ninkendo 8y ago
  In other words, don't treat it as a file any more?
  - JdeBP 8y ago
    Only if one also opines that memory mapping is a thing that one cannot generally do to files. (-:
    - zbentley 8y ago
      If we posit that memory mapping is a thing that one can generally do to files, then a ton of other abstractions break: how do you memory map a socket? Not a fixed piece of a socket's buffer, but communication on the socket itself?
- theoh 8y ago
  See my other comment about Plan 9. You can certainly organize to be able to mmap a file that represents a framebuffer, but that has nothing to do with the comment I was replying to. And it is exactly the kind of thing Torvalds is objecting to, quite reasonably: if the framebuffer device file exists only to be mmapped, there's no reason for it to exist as a file. Plan 9 used the file metaphor to achieve things like network transparency, which is a situation that precludes the use of mmap. (Though you could organize an OS to make it work that way.) If you just want to get access to a framebuffer as a memory-mapped resource, old style, there's no good reason for files to be involved.
coldtea 8y ago
It's the interface that counts though (write X at offset Y), not where the storage is. That's an implementation detail.
- theoh 8y ago
  Writing to a (non memory-mapped) file takes a call to write(), whereas setting pixels in a framebuffer might just be a memcpy(). I think, given the post we are commenting on, it is OK to distinguish these things. Historically, framebuffers are packed arrays of pixel values, and files aren't necessarily even seekable. These are well established norms. You could argue that the real interface for writing to an image/screen should involve two-dimensional locations, instead of a linear offset. This is what Plan 9's draw facility proposed, along with alpha compositing operators. That is certainly also a question of interface, but one at a higher level. So I don't agree that "write X at offset Y" is the ultimate, universal highest-level abstract standard for drawing on a raw raster image. It's more like an implementation detail from my point of view, actually :D

The point is that writing to a file is basically passing a message to the kernel. Writing to a framebuffer is writing straight into memory.

by theoh 8y ago

The point is that writing to a file is basically passing a message to the kernel. Writing to a framebuffer is writing straight into memory.

nly 8y ago

So mmap() the file?

ninkendo 8y ago
In other words, don't treat it as a file any more?
- JdeBP 8y ago
  Only if one also opines that memory mapping is a thing that one cannot generally do to files. (-:
  - zbentley 8y ago
    If we posit that memory mapping is a thing that one can generally do to files, then a ton of other abstractions break: how do you memory map a socket? Not a fixed piece of a socket's buffer, but communication on the socket itself?
theoh 8y ago
See my other comment about Plan 9. You can certainly organize to be able to mmap a file that represents a framebuffer, but that has nothing to do with the comment I was replying to. And it is exactly the kind of thing Torvalds is objecting to, quite reasonably: if the framebuffer device file exists only to be mmapped, there's no reason for it to exist as a file. Plan 9 used the file metaphor to achieve things like network transparency, which is a situation that precludes the use of mmap. (Though you could organize an OS to make it work that way.) If you just want to get access to a framebuffer as a memory-mapped resource, old style, there's no good reason for files to be involved.

coldtea 8y ago

It's the interface that counts though (write X at offset Y), not where the storage is. That's an implementation detail.

theoh 8y ago
Writing to a (non memory-mapped) file takes a call to write(), whereas setting pixels in a framebuffer might just be a memcpy(). I think, given the post we are commenting on, it is OK to distinguish these things. Historically, framebuffers are packed arrays of pixel values, and files aren't necessarily even seekable. These are well established norms. You could argue that the real interface for writing to an image/screen should involve two-dimensional locations, instead of a linear offset. This is what Plan 9's draw facility proposed, along with alpha compositing operators. That is certainly also a question of interface, but one at a higher level. So I don't agree that "write X at offset Y" is the ultimate, universal highest-level abstract standard for drawing on a raw raster image. It's more like an implementation detail from my point of view, actually :D