| |||||||||||||
|
| |||||||||||||
OLS: A proposal for a new networking APIOLS: A proposal for a new networking APIPosted Jul 23, 2006 11:01 UTC (Sun) by Los__D (subscriber, #15263)In reply to: OLS: A proposal for a new networking API by kleptog Parent article: OLS: A proposal for a new networking API
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.
(Log in to post comments)
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 (subscriber, #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.
|
|
||||||||||||