[go: up one dir, main page]

|
|
Log in / Subscribe / Register

OLS: A proposal for a new networking API

OLS: A proposal for a new networking API

Posted Jul 23, 2006 7:54 UTC (Sun) by kleptog (subscriber, #1183)
Parent article: OLS: A proposal for a new networking API

I think explicit DMA buffer management from user space is a good idea. Right now network cards use DMA extensivly, but so do graphics cards via DRI. Additionally, sound cards, scanners, camaras, printers, MPEG decoders/encoders, tv cards, etc could all benefit from a clear way to manage DMA buffers from user space. Rather than each subsystem coming up with their own allocation/deallocation routines.


to post comments

OLS: A proposal for a new networking API

Posted Jul 23, 2006 11:01 UTC (Sun) by Los__D (guest, #15263) [Link] (3 responses)

Management should only be pushed to userspace as long as there is a clear reason for it, we don't want a situation where the userspace app is expected to make their own driver to use the device.

OLS: A proposal for a new networking API

Posted Jul 23, 2006 13:07 UTC (Sun) by mattdm (subscriber, #18) [Link]

Even then, there'd be no reason for *every* app to do it -- that's what libraries are for....

OLS: A proposal for a new networking API

Posted Jul 23, 2006 16:51 UTC (Sun) by iabervon (subscriber, #722) [Link]

In cases where the DMA is of bulk uninterpreted or standard data, a driver wouldn't be necessary in userspace. It should work for userspace to ask the kernel a DMA handle that an MPEG-2 stream can be sent to to have the video card decode it with the hardware decoder, and then userspace plays video by passing the video data unmodified to the handle. Obviously, there's more going on, but the kernelspace driver would take care of that.

In the case of networking, the data is going to be the application's data, to be sent over the network, and it wouldn't matter what the device is to the userspace side.

OLS: A proposal for a new networking API

Posted Jul 27, 2006 3:02 UTC (Thu) by ianw (guest, #20143) [Link]

Well, why not? We might call this a "userspace driver", and abstract it to a library.

Suddenly (with an IOMMU) this driver can not crash the system any more than any other userspace process. If it does crash, we have a much higher chance that we can just restart it.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds