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]
Message-ID: <20131004233341.GA4028@kroah.com>
Date:	Fri, 4 Oct 2013 16:33:41 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	monstr@...str.eu, Pavel Machek <pavel@...x.de>,
	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, Alan Tull <atull@...era.com>,
	Dinh Nguyen <dinguyen@...era.com>,
	Philip Balister <philip@...ister.org>,
	Alessandro Rubini <rubini@...dd.com>,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Jason Cooper <jason@...edaemon.net>,
	Yves Vandervennet <rocket.yvanderv@...il.com>,
	Kyle Teske <kyle.teske@...com>,
	Josh Cartwright <joshc@....teric.us>,
	Nicolas Pitre <nico@...aro.org>,
	Mark Langsdorf <mark.langsdorf@...xeda.com>,
	Felipe Balbi <balbi@...com>, linux-doc@...r.kernel.org,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	David Brown <davidb@...eaurora.org>,
	Rob Landley <rob@...dley.net>,
	"David S. Miller" <davem@...emloft.net>,
	Joe Perches <joe@...ches.com>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH v2 0/1] FPGA subsystem core

On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote:
> On 10/04/2013 10:44 AM, Michal Simek wrote:
> > 
> > If you look at it in general I believe that there is wide range of 
> > applications which just contain one bitstream per fpga and the 
> > bitstream is replaced by newer version in upgrade. For them 
> > firmware interface should be pretty useful. Just setup firmware 
> > name with bitstream and it will be automatically loaded in startup 
> > phase.
> > 
> > Then there is another set of applications especially in connection 
> > to partial reconfiguration where this can be done statically by 
> > pregenerated partial bitstreams or automatically generated on 
> > target cpu. For doing everything on the target firmware interface 
> > is not the best because everything can be handled by user 
> > application and it is easier just to push this bitstream to do 
> > device and not to save it to the fs.
> > 
> > I think the question here is if this subsystem could have several 
> > interfaces. For example Alan is asking for adding char support. 
> > Does it even make sense to have more interfaces with the same 
> > backend driver? When this is answered then we can talk which one 
> > make sense to have. In v2 is sysfs and firmware one. Adding char
> > is also easy to do.
> > 
> 
> Greg, what do you think?
> 
> I agree that the firmware interface makes sense when the use of the
> FPGA is an implementation detail in a fixed hardware configuration,
> but that is a fairly restricted use case all things considered.

Ideally I thought this would be just like "firmware", you dump the file
to the FPGA, it validates it and away you go with a new image running in
the chip.

But, it sounds like this is much more complicated, so much so that
configfs might be the correct interface for it, as you can do lots of
things there, and it is very flexible (some say too flexible...)

A char device, with a zillion different custom ioctls is also a way to
do it, but one that I really want to avoid as that gets messy really
quickly.

thanks,

greg k-h
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ