Jon Smirl wrote:
On 6/22/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
I'll add a new map type DRM_VSHM. When initializing, the chip specific
driver needs to do something like this:
if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0)))
goto err_g1;
The map needs to be created in the driver. Opening it up to a normal
user is a DOS hole where the kernel can be run out of memory. Use
getmap to find the map from user space.
I don't understand what the difference is between DRM_SHM and DRM_VSHM.
I understand all the security issues and the root-only issues, so
please don't rehash that. Can you just tell me, for example, what
documentation would you put in libdrm/xf86drm.h for the DRM_VSHM enum?
Adding a new map type "so that you can tell them apart" doesn't make a
lot of sense to me. Won't two different maps have different offsets?
Isn't that enough to differentiate between them?
Yes the offsets will be different. But how does user space know which
one is being used for sarea and which for xvideo support?
We could use a flag instead of map type but we are running out of
flags. There are 1,000s of map types available.
Why not do it like this:
1). Nobody uses this feature today. Therefore I think it is ok to just
ignore my request for the time being. For backward compatibility,
drmAddMap would have to return an error when asked to map a shared
memory map without the "contains lock" flag set. This is actually not
backwards compatible but shouldn't bother anyone since it is not used.
2) When I or somebody else feels the need for a secondary sarea we'll
implement another IOCTL for it. Call it drmShmGet(dev, area, &handle).
The client can choose between "area" secondary areas, and the
device-specific driver sets up the number and size of each area at init,
but they don't actually need to be created before the first call to
drmShmGet for that area. No need for flags, No restriction to a single
secondary sarea. No kernel memory waisted and no security hole. The
IOCTL should be OK to use for any authorized client.
/Thomas
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
