On Wed, Jan 05, 2011 at 02:56:05AM +0000, Christos Zoulas wrote: > In article <20110104120934.ga30...@britannica.bec.de>, > Joerg Sonnenberger <jo...@britannica.bec.de> wrote: > >Hi all, > >while investigating ways to access the auxillary vector, I found that we > >currently don't deal correctly with struct ps_strings in 32bit compat. > >This structure is placed by the kernel into the initial stack and > >referenced in userland by __ps_strings. It is used by setproctitle(3) > >and therefore e.g. by programs that want to include a status report in > >the ps(1) output. This naturally works only by chance, if at all in > >compat32. How do we want to deal with it? > > > >Variant 1: Leave it as broken. It should be said that having reliable > >ps_strings could speed up ld.elf_so a bit. > > > >Variant 2: Introduce two methods for obtaining and setting ps_strings of > >a specific process and hook those into the normal exec mechanism. This > >would in theory allow emulations pretty arbitrary data structures. > > > >Other options that are better? > > Something like a mapped page for each process to store: > > - thread id > - clock > - optimized memcpy/memmove/memset for the processor > - ps_string info > > etc. This could be mapped at a known location.
Thread is is not a process property. ps_string is a global property, but moving it into some magic area doesn't help compat. memcpy/... can already be obtained with ld.so.conf, so I am not sure how much that really belongs in this either. In short, what can be done with a comm page is a separate topic, but I don't see how it actually fixes the problem in my original mail. Joerg
