linux-kernel - Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

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: <20150121160151.453ba403@lxorguk.ukuu.org.uk>
Date:	Wed, 21 Jan 2015 16:01:51 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	atull <atull@...nsource.altera.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Pavel Machek <pavel@...x.de>, hpa@...or.com,
	Michal Simek <monstr@...str.eu>,
	Michal Simek <michal.simek@...inx.com>, rdunlap@...radead.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	devicetree@...r.kernel.org, robh+dt@...nel.org,
	Grant Likely <grant.likely@...aro.org>, iws@...o.caltech.edu,
	linux-doc@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	philip@...ister.org, rubini@...dd.com,
	Steffen Trumtrar <s.trumtrar@...gutronix.de>,
	jason@...edaemon.net, kyle.teske@...com, nico@...aro.org,
	Felipe Balbi <balbi@...com>, m.chehab@...sung.com,
	davidb@...eaurora.org, Rob Landley <rob@...dley.net>,
	davem@...emloft.net, cesarb@...arb.net, sameo@...ux.intel.com,
	akpm@...ux-foundation.org,
	Linus Walleij <linus.walleij@...aro.org>, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	galak@...eaurora.org, devel@...verdev.osuosl.org,
	Alan Tull <delicious.quinoa@...il.com>,
	dinguyen@...nsource.altera.com, yvanderv@...nsource.altera.com
Subject: Re: [PATCH v8 2/4] fpga manager: add sysfs interface document

On Thu, 15 Jan 2015 22:54:46 +0200
Pantelis Antoniou <pantelis.antoniou@...sulko.com> wrote:

> Hi Alan,
> 
> > On Jan 15, 2015, at 22:45 , One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> > 
> > On Thu, 15 Jan 2015 11:47:26 -0700
> > Jason Gunthorpe <jgunthorpe@...idianresearch.com> wrote:
> >> It is a novel idea, my concern would be that embedding the FPGA in the
> >> DT makes it permanent unswappable kernel memory.
> >> Not having the kernel hold the FPGA is best for many uses.
> > 
> > If you have a filesysytem before the FPGA is set up then it belongs in
> > the file system. As you presumably loaded the kernel from somewhere there
> > ought to be a file system (even an initrd).
> > 
> 
> Request firmware does not imply keeping it around. You can always re-request
> when reloading (although there’s a nasty big of caching that needs to be
> resolved with the firmware loader).

Which comes down to the same thing. Unless you can prove that there is a
path to recover the firmware file that does not have any dependancies
upon the firmware executing (and those can be subtle and horrid at times)
you need to keep it around for suspend/resume at least and potentially
any unexpected error/reset.

> One of the ideas rolling about is to put the device tree overlay blob in
> an EEPROM and then load it from there (not from the filesystem).

That's a fine example of one you can probably always get to and avoid
caching. However if its in eeprom you don't need request_firmware anyway !

> Can we please not use ioctls if possible. Configfs seems to work just fine
> for configuration and for any other higher speed API we should use read/write/mmap.

You don't have the needed state in configfs as far as I can see.

> Ioctls are a pain for scripting and interpreted languages usually.

You can do ioctls in perl just fine if you are mad (and if you are
using perl you are ;-) ) while python has a complete explicit fcntl.ioctl
model.

> Making the API handle partial reconfiguration from day one might be pushing tricky.
> I don’t remember any case where I came across a need for it.

Agreed - I don't see the point in adding it until someone needs it and can
describe what is needed accurately.

Alan
--
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/