[LITMUS^RT] RFC control page & test suite fixes

[Björn Brandenburg]

On Jun 27, 2012, at 2:04 PM, Andrea Bastoni wrote:

> On 06/27/2012 08:35 AM, Björn Brandenburg wrote:
>> 
>> On Jun 26, 2012, at 7:33 PM, Christopher Kenna wrote:
>> 
>>> On Mon, Jun 25, 2012 at 8:58 AM, Björn Brandenburg <bbb at mpi-sws.org> wrote:
>>>> 
>>>> For the kernel, I've pushed prop/control-page-fixes, which improves the control page driver (but does not change the existing features).
>>>> 
>>>> Please let me know if you have any comments.
>>> 
>>> One question: Is __S011 more consistent across architectures (and
>>> maybe PAGE_SHARED is not)? I thought they were equivalent but did not
>>> dig deeply into the source for all architectures.
>> 
>> Good point, I wasn't sure about this. A quick search reveals that PAGE_SHARED is defined by most (all?) architectures, but that it is not used in architecture-indepdendent code (couldn't find it anywhere in include/, kernel/, mm/, net/, ipc/, or fs/). In contrast, __S011 is used in mm/mmap.c, so it has to be defined by all architectures. So I went with __S011.
> 
> Yep. I checked a bit, and it seems that the idea of PAGE_SHARED (NX,r/w) is not
> the same across different architectures. For example, on microblaze or motorola
> m68k, even if you'd like to have a 011 page, you end up with an executable page...
> 
>> Do you know of a place that documents which constants the VM subsystem expects to be defined by each architecture?
> 
> I believe the VM subsystem does not expect anything from architectures. My take
> is that the protection_table in mm/mmap.c just lists the desired access
> permissions, while the architecture layer maps those permissions on the
> appropriate (and available) PAGE settings. Some architectures (e.g., x86) can do
> that at compile time, while others (e.g., sparc) overwrite the protection_table
> with the appropriate settings at runtime during the initialization of caches.
> 
>>> Also, your umlaut caused arch/x86/include/asm/feather_trace_32.h and
>>> arch/x86/include/asm/feather_trace_64.h to flip to UTF-8 now. This is
>>> probably not an issue though, correct?
>> 
>> Ooops. I think it should be ok since it's only in a comment. If it causes problem, let me know and I'll revert it.
> 
> These are on staging, right, not on control-page-fixes... I thought I was
> missing something ;) UTF-8 should not be an issue anyway...
> 
> The patches look good to me!


Chris, Andrea, thanks a lot for looking through the patches. The proper way to handle __S011 is still not entirely clear to me, but I think what's implemented works for now. Let me know if you think another way would be better, otherwise I'll merge the branch next week.

Thanks,
Björn