sbefifo userspace api

[Alistair Popple]

Hi,

On Sat, 25 Feb 2017 11:22:00 AM Venkatesh Sainath wrote:
>
> On 25/02/17 11:13 AM, Brad Bishop wrote:
> >> 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?
> Agreed. Also, a write(fd1), write(fd2), read(fd1) should not be allowed
> as it can confuse the SBE which is waiting for its downstream fifo to be
> pulled by BMC and it receives more data on its upstream fifo. A write on
> a given fd should always be followed by a read on the same fd. Two
> writes or two reads should not be followed in sequence. Two back-to-back
> reads can result in sbefifo DD experiencing a false sbe response timeout
> as there is nothing to be sent by SBE and sbefifo DD is waiting on the
> downstream fifo.

I think you are confusing the read/write system calls with the
read/write calls to the fifo. The kernel driver is responsible for
ensuring a sequence of write(fd1), write(fd2), read(fd1) syscalls
results in a sequence of write(fd1), read(fd1), write(fd2) calls to
the SBE FIFO.

- Alistair

> >> -Venkatesh
> > -brad
>