On Tue, May 12, 2009 at 2:21 AM, Kanigeri, Hari <[email protected]> wrote: > Felipe, > >> >> IMHO the only sensible way to approach this is to create a new ioctl >> for a special restrictive mapping where user-space specifies if the >> memory area is read-only or write-only and the size must be the real >> size. This also has advantage that it does not break legacy >> applications. > > -- How are you planning to inform LCML about choosing this new ioctl as > opposed to the regular one? Any ways, I think the ulMapAttr flag in > DSPProcessor_Map function can be extended to provide the information about > read-only or write-only. The only issue is with this we can enforce the > checks on only the applications that set this check and it will not cover the > buffer alignment issues with the applications that don't enforce this check.
Inform? LCML can use the new ioctl by simply using it: ioctl(handle, <new id>, <new arg>) >>While we are at it, this new mapping could do >> PROC_ReserveMemory at the same time so that the user-space application >> doesn't get a chance to modify the pa. >> > -- What does PROC_ReserveMemory has to do with pa ? Sorry, I don't know what kind of address PROC_ReserveMemory returns (va?), but I don't see any point in having PROC_ReserveMemory and PROC_Map as separate ioctls -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
