sbefifo userspace api

[Brad Bishop]

> On Feb 25, 2017, at 12:14 AM, Venkatesh Sainath <vsainath at linux.vnet.ibm.com> wrote:
> 
> 
> 
> On 24/02/17 11:44 AM, Alistair Popple wrote:
>> On Thu, 23 Feb 2017 10:01:15 PM Brad Bishop wrote:
>>> Based on what we’ve discussed here and a couple offline discussions,
>>> I’m making some assertions below.  I’d like for this note to be a
>>> “last call for discussion” (as much as that is possible) so we can
>>> start hacking; please try and raise any concerns by sometime next week.
>>> 
>>> - sbefifo DD will implement read and write system calls.  A write
>>> will put data in the upstream fifo.  A read will pull data out of
>>> the downstream fifo.
> Brad,
> Thanks for summarising the discussion. Instead of independent read/write calls, I was looking for a single ioctl(submit) operation which would always do a write of the incoming data packet to the upstream fifo followed by a read of a byte stream from the downstream fifo. There can be multiple users who open file descriptors to the sbe fifo in write mode. However, each ioctl(fd,submit,data) operation will be protected such that no two submit operations will happen in parallel.

The driver can/will still provide this protection, even with a read/write
interface.

> This way (a) the users dont have to know the semantics of the sbe fifo status bits ( data valid / end-of-transmission)

I don’t think a read/write interface necessitates this.

> and (b) there wont be any collision of write and read operations between two users.

If a user writes to an fd, the sbe response will only come out with
a read on that same fd.  If some other fd is read from (before or after
read is called on the first fd), that read is just going to block (until
_that_ fd is written to).

> I am hoping this does not violate any linux DD norms.

I’ve been told by multiple folks that read/write is the “interface of least
surprise” in the general Linux sense.  Given that, I chose read/write over
an ioctl to maximize our chances of getting this driver incorporated into
upstream Linux.

A wrapper to get a submit-like interface could look like this:

int submit(const char* in, size_t len, char** out)
{
    char buf[1024];
    ssize_t read = 0;

    int fd = open(“/dev/sbefifo”);
    int rc = write(fd, in, len);
    
    while((rc = read(fd, &buf, sizeof(buf))) > 0)
    {
       read += rc;
       /* copy out… */
    }

    return read;
}

That should be workable, right?

> 
> -Venkatesh

-brad