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: <D466D9FF-25DA-4765-9469-128733BEBC4D@konsulko.com>
Date:	Wed, 21 Jan 2015 18:33:12 +0200
From:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
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>,
	Randy Dunlap <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,
	Andrew Morton <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

Hi Alan,

> On Jan 21, 2015, at 18:01 , One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> wrote:
> 
> 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.
> 

In that case the only safe place to put it is in the kernel image itself, which
is something the firmware loader already supports.

>> 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 !
> 

Sure, I never said that request_firmware is the only way to get hold of a blob.
It just happens to be the most convenient one for the kernel (when the blob
resides somewhere on a filesystem).

>> 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.
> 

Sure, but there’s no reason for it not to be there.

>> 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.
> 

Sure, it can be made to work, but it is a pain.

>> 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.
> 

/me nods.

> Alan

Regards

— Pantelis

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