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: <bed1d7ce1b984c79acc75a47495cb959@BL2FFO11FD043.protection.gbl>
Date:	Mon, 12 Jan 2015 14:48:47 +0100
From:	Michal Simek <michal.simek@...inx.com>
To:	Pavel Machek <pavel@...x.de>, atull <atull@...nsource.altera.com>
CC:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	<jgunthorpe@...idianresearch.com>, <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 01/12/2015 09:45 AM, Pavel Machek wrote:
> On Sun 2015-01-11 10:29:00, atull wrote:
>> On Sat, 10 Jan 2015, Pavel Machek wrote:
>>
>>> On Sat 2015-01-10 10:10:51, Pantelis Antoniou wrote:
>>>> Hi Pavel,
>>>>
>>>>> On Jan 9, 2015, at 22:56 , Pavel Machek <pavel@...x.de> wrote:
>>>>>
>>>>> On Fri 2015-01-09 13:14:24, atull wrote:
>>>>>> On Wed, 7 Jan 2015, Pavel Machek wrote:
>>>>>>
>>>>>>> On Tue 2015-01-06 14:13:37, atull@...nsource.altera.com wrote:
>>>>>>>> +
>>>>>>>> +What:		/sys/class/fpga_manager/<fpga>/firmware
>>>>>>>> +Date:		October 2014
>>>>>>>> +KernelVersion:	3.18
>>>>>>>> +Contact:	Alan Tull <atull@...nsource.altera.com>
>>>>>>>> +Description:	Name of the FPGA image file to load using firmware
>>>>>>>> class.
>>>>>>>
>>>>>>> This one is ugly: it unneccessarily passes firmware name through the
>>>>>>> kernel. Just make interface and code simpler by always passing
>>>>>>> "socfpga-fpga-image" or something like that.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> 									Pavel
>>>>>>
>>>>>> Hi Pavel,
>>>>>>
>>>>>> It might be ugly.  It's not unnecessary.  Some uses of FPGAs involve
>>>>>> switching out the FPGA images dynamically under control of the userspace.
>>>>>
>>>>> Then configure udev to load right firmware for you, or ln -s
>>>>> image-i-want-now socfpga-fpga-image to select the one to read…?
>>>>>
>>>>
>>>> Who said that udev is going to be available in the kind of system this is going to end in?
>>>
>>> Noone.
>>>
>>>> Doing ln -s tricks to load a different image? Really?
>>>
>>> But if you don't have udev, you can do ln -s. It is better than
>>> open-coding symlink functionality into
>>> /sys/class/fpga_manager/<fpga>/firmware ... cause that's what this is.
>>>
>>> Actually, clean implementation of "firmware" would be symlink in
>>> sysfs; but I'd say that would be overdoing it.
>>>
>>>> I say the interface is fine as it is.
>>>
>>> I say it is not.
>>> 									Pavel
>>
>> Hi Pavel,
>>
>> I see that we could do it that way and it would eliminate one of the
>> sysfs files (../fpga_manager/<fpga>/firmware).  Either way we are assuming
>> that there are fpga images in the filesystem in the firmware search path,
>> so I don't see why adding a piece of indirection (symlink) makes things
>> better.
> 
> Well.. you are basically re-implementing symlink with
> ../fpga_manager/<fpga>/firmware "file" in sysfs, and doing it
> badly. It has no advantages over real symlink.
> 
>> We want to be able to switch out the FPGA image
>> under control of userspace.  So we don't want an interface that makes
>> it more cumbersome or tries to pretend that there's only one image.
> 
> What is cumbersome about symlink? Why is "fake" symlink in sysfs better?
> 
>> Previous uses of the firmware layer has been to use it to load once after
>> bootup; this is different since some use cases will want to switch out
>> the FPGA image.  If someone wants there to be only one FPGA image on
>> the FGPA forever, they will probably not be using this framework; their
>> FPGA will probably be loaded before Linux boots up.
> 
> Why? I have just one image on the fpga, and would prefer to load it
> from Linux.

Pavel: These patches target staging and sysfs interface doesn't need to be stable
at this time. I would prefer to add these patches to staging for 3.20
and feel free to send the patch which fix this.
With your code will be exactly clear how you want to use it and we can
talk about it.

Thanks,
Michal



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