Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

4
  • I am not sure what your question is. The driver can certainly "see" which process is writing right now, but what do you expect it to do with this information? Whenever process A, or B, or C etc. writes to the device, a character is output, except if spidev uses some locking protocol. Commented Apr 6, 2021 at 23:39
  • So the driver reads and sends one byte from A, then one from B, then C, A and so on, until all streams are empty? Or does it empty every stream before going to the next? Is the resulting SPI stream ABCABCBBC or rather AABBBCCC? Commented Apr 6, 2021 at 23:43
  • I don't think the driver has a notion of "streams". It could wait until process A closes the device file, but I can't imagine it does that. However, according to the answer, it does write out an entire buffer without interference from other processes. The buffer has a max size of bufsiz, which is likely to be a rather small number. Commented Apr 7, 2021 at 1:36
  • In general, I would very much expect writes to be atomic wrt. each other. If one process writes aaa and another writes bb, the result better be either aaabb, or bbaaa (for non-seekable streams). POSIX dictates that for regular files and pipes up to some maximum write length (PIPE_BUF), and I'd be surprised if the same didn't apply to stream sockets (e.g. TCP) or "regular" UART serial ports on serious systems. (For regular files, the writes can of course overlap, but they still can't interleave.) Anyway, SPI isn't exactly a stream protocol, it has to guarantee intact transfers. Commented Apr 7, 2021 at 21:05