Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20180818155724.GA22569@kroah.com> <20180828103817.GB1397@do-kernel>
In-Reply-To: <20180828103817.GB1397@do-kernel>
From:   Todd Poynor <toddpoynor@google.com>
Date:   Tue, 28 Aug 2018 04:20:20 -0700
Message-ID: <CAAW3YpabUJHRT34=PboTfW-NJBeCinrfrzwf2Jp_nT2thDJoaQ@mail.gmail.com>
Subject: Re: [GIT PULL] Staging/IIO driver patches for 4.19-rc1
To:     darwish.07@gmail.com
Cc:     Greg KH <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        akpm@linux-foundation.org, sfr@canb.auug.org.au,
        Rob Springer <rspringer@google.com>,
        John Joseph <jnjoseph@google.com>,
        LKML <linux-kernel@vger.kernel.org>, devel@linuxdriverproject.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Aug 28, 2018 at 3:38 AM Ahmed S. Darwish <darwish.07@gmail.com> wrote:
>[...]
> On Sat, 18 Aug 2018 17:57:24 +0200, Greg KH wrote:
> [...]
> > addition of some new IIO drivers.  Also added was a "gasket" driver from
> > Google that needs loads of work and the erofs filesystem.
> >
>
> Why are we adding __a whole new in-kernel framework__ for
> developing basic user-space drivers?
>
> We already have a frameowrk for that, and it's UIO. [1] The UIO
> code is a very stable and simple subsystem; it's also heavily used
> in the embedded industry..

Yeah, it's clear all the userspace I/O framework code needs to move to
UIO with some patches to add agreed-upon new pieces.  I think everyone
agrees this code shouldn't move out of staging until that happens.  A
whole lot of work is needed on these drivers, and UIO conversion is on
my list to address soon.

>
> I've looked at the gasket documentation [2], and the first user
> of this new in-kernel API [3], and this is almost replicating UIO
> it's not funny. [4] True, the gasket APIs adds some extra new
> conveniences (PCI BAR re-mapping, MSI, ..), but there's no
> technical reason this cannot be added to the UIO code instead.
>
> More-over, the exposed user-space API is just some ioctls. So if
> google hase some shipped user-space code that is using this,
> hopefully the driver can still be re-implemented through UIO
> without changing these bits..
>
> Thanks,
>
> [1] https://www.kernel.org/doc/html/v4.18/driver-api/uio-howto.html
> [2] drivers/staging/gasket/gasket_core.h :: struct gasket_driver_desc
> [3] drivers/staging/gasket/apex_driver.c
> [4] include/linux/uio_driver.h
>
> --
> Darwi
> http://darwish.chasingpointers.com

Thanks -- Todd