I am not sure there really is a best list for this, but this is the
closest I can think of.
I am working on host software, for a series of cards
(www.picocomputing.com)
All of these cards have an FPGA, most have a processor, memory,
flash and other resources.
They have different flavor FPGA, CPU's and busses (compact Flash,
PCI, CardBus, Express Bus, ....)
The cards can run standalone, and they can run uCLinux, Linux, or
GreenHills, or ...
But when they are inserted into a Linux Host (there is already
windows host software)
From the host side there are several major tasks that might be
performed,
Reading writing target memory, IO space, preprogramming the FPGA,
Flash,
or reading/writing to the hardware implemented in the FPGA - which
may or may not require interaction with
the target OS. The performance and bandwidth requirements of
data-transfers varies greatly,
most being fairly mellow, but occasionally either the bandwidth or
latency requirements can be high.
Some of the above is vague - We are not developing a specific peice
of hardware for a specific use.
We are working on a product and development environment that has
nearly infinite uses.
We have evolved a virtual channel architecture that is to allow
creating IP that goes into the FPGA, and can be
accessed by applications on the host. There can be multiple cards in
the same host (in some applications large numbers)
despite all of the above things are not all that complex, just
incredibly flexible.
Anyway that is the BIG picture.
Our/my original implementation of a driver(s) for this was a
character driver for each card specific to its bus type,
with minor device numbers for reading writing different regions, and
a large collection of ioctl's to handle special functions.
But the vast majority of actions consist of read/write.
I have been trying to decide if it make sense to rewrite the driver
as a VFS driver, with special file names for each channel or
functional unit.
I have also been trying to digest enough information on sysfs to
determine if that is an appropriate approach.
Basically I am trying to decide what kind of driver provides the
best potential solution.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
