> 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...?
Your conceptual model is wrong. FPGA firmware is dynamic. There are
already people who lazy reload FPGA firmware on taskswitches. This
proposed fpga manager is broken but it's broken in exactly the reverse
direction to the one you are arguing for.
There are plenty of people today who treat the FPGA as an entirely
dynamic resource. It's not like flashing a controller, its near
immediate.
The udev/sysfs model is broken because
- it's too slow for dynamic switching
- it doesn't address permissions
- it doesn't address namespaces
- it doesn't address dynamic management of resources (open/use/close)
with dyanmic resource recovery on the final close as is the Unix way.
not because FPGA's are some static boot time resource.
If you look at all the academic work on this you see the same kind
of dynamic usage, even more so.
The library API you actually need is much closer to
/* Get my firmware */
fw = fpga_openfirmware("foo.fpga");
/* Get me a suitable FPGA for it */
fd = fpga_alloc(&w);
/* Load it */
fgpa_load(fd, "foo.fpga");
do_shit(fd);
fpga_close(fd);
You want to be able to have things like your game just load up an audio
physics engine, lob it into a random fpga, play it, drop it. Likewise
lots of other FPGA apps - video processing for example, crypto, format
convertors, gesture analysers and so on. Think a world where there are
gimp filters that want to just grab an fpga for 3 seconds.
Its completely dynamic and it will get more so as we switch from the
painful world of VHDL and friends to high level parallel aware language
compilers for FPGAs and everyone will be knocking up quick FPGA hacks.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
