On 05.07.2017 23:30, Didier Kryn wrote:
> And there are a whole menagerie of addressing and transfer protocols,
> including chained dma transfers
Especially things like DMA are naturally kernel domain. I wouldn't ever
allow any direct access to dma controllers from userland.
> In our case it is waveform digitizers and the interaction is so >
complex that it cannot be done in a kernel module
What exactly is so complex about that ? Smells like a typical task
for IIO to me.
> Some others consider there should be one driver per VME device you
> want to talk to, on top of the raw VME driver.
Exactly.
> These people only ever had to deal with simplistic devices. Gabriel
> Paubert has never seen an application transfering more than a few bytes,
> while we are transferring data at 320MB/s.
Those kind of things usually involve proper timing, caring about
caching, etc, etc. Natural kernel domain.
>> Which absurdities, exactly ?
> Bus errors were not reported to the application but instead caused
> a message to syslog! This makes it hard to use; or your application
> should monitor the log files!
Yes, that's hackish, of course.
> This isn't the case here. AFAIU, their BSP contains a VME driver
> and a device tree. I think it's all GPL. Their buzyness is to send
> hardware and they make sure their clients can use it.
Looks like your vendor is an exception.
> These are SBCs with everything soldered: VME, flash memory, UARTs,
> USB hub, Sata controllers, Ethernet ports etc... And you just plug it
> into a VME crate. It makes no sense to develop a board like this to use
> a dozen of them. We made the digitizers and it was already a big deal
> for our small team.
>
> Could you develop what is IIO for DAQ devices?
What's the difference between you digitizes and usual DAQ devices ?
What do you actually do with them ?
Some clear requirements on the table, please ;-)
> Is it something allowing to write drivers in user space?
What kind of drivers do you wanna have in userland ? And why ?
--mtx
::
Re: [DNG] kernel drivers [WAS: How …
