Re: /dev/mem implementation

[Felix Rubinstein]

The usecase is broadcom 10GbE switch driver which maps DMA memory to userspace.
I can find one more libe1000 which uses char driver to map DMA memory
to userspace too.
So, how can I implement userspace drivers in recent kernels which want
to map DMA memory to userspace if STRICT_DEVMEM or PAT (either of
them) are enabled.

The motivation to implement network drivers is not new and there are
here and there mini projects to bypass Linux networks stack to gain
better latency as stack has lots of locks around, buffer copying
(userspace to kernel and vice versa), etc... which only add latency.

Thanks,
Felix R.

On Sun, Jan 17, 2010 at 7:40 PM, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
> On Sun, 17 Jan 2010 18:47:10 +0200
> Felix Rubinstein <felixru@xxxxxxxxx> wrote:
>
>> I see the motivation to limit the access to DRAM from root account
>> CONFIG_STRICT_DEVMEM by mmap'ing /dev/[k]mem but it's easily overruled
>> by simple char driver and implementing mmap of it's own totally
>> bypassing all limitations.
>>
>> What do you think about it guy?
>> Appreciate it.
>
> the reason PAT bans parts of /dev/mem is simple: it is illegal to have
> mapping aliases (different cachability) for the same physical page.
> Normal kernel APIs take care of this for the normal case, but /dev/mem
> would be a back door into that.
> This is a hardware imposed requirement, and violating the rule can have
> really nasty consequences... hence the PAT code just not allowing it.
>
> If you feel that you have a valid use case where you really want do
> muck with such memory, it might be a good idea to explain that
> usecase....
>
> --
> Arjan van de Ven        Intel Open Source Technology Centre
> For development, discussion and tips for power savings,
> visit http://www.lesswatts.org
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/