linux-kernel - Re: [PATCH 1/1] Add mkopci driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 21 Mar 2015 20:24:46 +0300
From:	Sergej Bauer <sergej.bauer@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Richard Weinberger <richard.weinberger@...il.com>,
	Paul Bolle <pebolle@...cali.nl>, linux-kernel@...r.kernel.org,
	gregkh@...uxfoundation.org
Subject: Re: [PATCH 1/1] Add mkopci driver

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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/