From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751720AbbCURYv (ORCPT ); Sat, 21 Mar 2015 13:24:51 -0400 Received: from mail-la0-f41.google.com ([209.85.215.41]:33698 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751645AbbCURYu (ORCPT ); Sat, 21 Mar 2015 13:24:50 -0400 From: Sergej Bauer To: Arnd Bergmann Subject: Re: [PATCH 1/1] Add mkopci driver Date: Sat, 21 Mar 2015 20:24:46 +0300 User-Agent: KMail/1.13.7 (Linux/3.18.9; KDE/4.8.4; x86_64; ; ) Cc: Richard Weinberger , Paul Bolle , linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org References: <201503201510.26639.sergej.bauer@gmail.com> <201503211741.11580.sergej.bauer@gmail.com> <201503211641.42508.arnd@arndb.de> In-Reply-To: <201503211641.42508.arnd@arndb.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201503212024.46928.sergej.bauer@gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ok, I realized uselessness of merging this driver... And you brought me to a standstill: > passthrough. In either case, both the ioctl interface and the procfs interface have no future But what will be after ioctl? On Saturday 21 March 2015 18:41:42 Arnd Bergmann wrote: > On Saturday 21 March 2015, Sergej Bauer wrote: > > Richard, thanks for your review. > > > > But I still have several notes about driver: > > > > > - You add new proc files, which is not really welcomed. Please consider sysfs. > > That will break a bunch of userspace applications, which use proc-files for several years (as long as from 2006 > > year) > > > > > > BTW: Forgot to mention that this sounds like a job for UIO or VFIO. > > And again, you are right. But, again, there a number of applications wich use /proc/mkopci/core > > > > But, of course, there may be decided that the kernel main line - this is not the place for such a driver. :) > > If the driver is suitable anyway, patch is at the end of this message > > I don't think we should merge the driver with the proposed user interface. You can either > create a high-level abstraction for MIL-STD-1553, or use UIO or VFIO to provide a trivial > passthrough. In either case, both the ioctl interface and the procfs interface have no > future, and existing user space programs need to adapt. > > There is nothing wrong with adding a driver for this hardware, but I'd rather see it done > properly than having an ad-hoc user space interface that was never reviewed publically > before it got used by applications. > > Arnd >