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: <54E37569.80508@landley.net>
Date:	Tue, 17 Feb 2015 11:07:53 -0600
From:	Rob Landley <rob@...dley.net>
To:	Pavel Machek <pavel@...x.de>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	atull <atull@...nsource.altera.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 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, 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



On 02/15/2015 04:40 PM, Pavel Machek wrote:
> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
>> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
>> My point is that the current firmware layer is overly cautious and
>> FPGAs are very big. My current project on small Xilinx device has a
>> 10MB programming file. The biggest Xilinx device today has a max
>> bitfile size around 122MB.
>>
>> So keeping that much memory pinned in the kernel when I can prove it
>> is uncessary for my system (either because there is no suspend/resume
>> possibility, or because I know the CPU can always access the
>> filesytem) is very undesirable.
> 
> Well, your current device aalso has 1GB RAM, no?

Unnecessarily pinning 10% of your ram is a good solution?

> I'd say the general case is "store bitstream in RAM" we can add
> optimalizations later.

We _have_ a firmware loading layer that doesn't store other kinds of
firmware in pinned kernel memory. I guess that was retroactively a bad
idea. As was the "freeing kernel memory" part at the end of boot.

There honestly are small embedded devices. Still. When you have your
DRAM on the SOC instead of as an external chip, a gigabyte is not in the
cards.

If you're saying "Linux should not care about this niche, let's open
ourselves to a new disruptive technology attack with that as its initial
protected base, because the average kernel developer age is about 44 now
and we're not really recruiting anybody younger than that, so we'll all
be dead before we have to care about being replaced"...

Rob

(At $DAYJOB we're building a chip that runs off of induction current to
retrofit monitoring sensors onto things. It currently has 64 megs of ram
but they're trying to trim that _down_ to free up chip space.)
--
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/