From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751539AbbCUPlz (ORCPT ); Sat, 21 Mar 2015 11:41:55 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:53657 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751411AbbCUPlx (ORCPT ); Sat, 21 Mar 2015 11:41:53 -0400 From: Arnd Bergmann To: Sergej Bauer Subject: Re: [PATCH 1/1] Add mkopci driver Date: Sat, 21 Mar 2015 16:41:42 +0100 User-Agent: KMail/1.12.2 (Linux/3.8.0-35-generic; KDE/4.3.2; 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> In-Reply-To: <201503211741.11580.sergej.bauer@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201503211641.42508.arnd@arndb.de> X-Provags-ID: V03:K0:TdRt2Fsd55N2Ikf6zUzZUPPgsa7T3qAOgWd7SVgv25KwPd1/ErA 9bhzCy4eSv+1CroBXjsEyETniOnb0lkQ4533D6v+SjhKr/T6irZhZuGuxnLm13WGmQXpwp0 2uA0Wn/nucLVIyNvdn3LQPZdMhmb3T0YrwzoeVP8H5m3n0AcX4E9tyE170CET/tA69kS67A pv+ngb1WZpnpscZ2S/Tiw== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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