On Tue, May 12, 2009 at 2:21 AM, Kanigeri, Hari <h-kanigeri2@xxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
