On Wed 30 Jun 2010 17:46, Mike Frysinger pondered: > On Wed, Jun 30, 2010 at 16:09, Robin Getz wrote: > > On Wed 30 Jun 2010 02:05, Mike Frysinger pondered: > >> On Mon, Jun 28, 2010 at 17:55, Robin Getz wrote: > >> > On Thu 24 Jun 2010 06:19, Song, Barry pondered: > >> >> On Mon 21 Jun 2010 06:19, [email protected] pondered: > >> >> > Modified: trunk/arch/blackfin/kernel/ptrace.c (8929 => 8930) > >> >> > > >> >> > @@ -27,6 +27,7 @@ > >> >> > #include <asm/fixed_code.h> > >> >> > #include <asm/cacheflush.h> > >> >> > #include <asm/mem_map.h> > >> >> > +#include <asm/mmu_context.h> > >> >> > > >> >> > /* > >> >> > * does not yet catch signals sent when the child dies. > >> >> > @@ -135,6 +136,13 @@ > >> >> > if (start >= FIXED_CODE_START && start + len < FIXED_CODE_END) > >> >> > return 0; > >> >> > > >> >> > +#ifdef CONFIG_APP_STACK_L1 > >> >> > + if (child->mm->context.l1_stack_save) > >> >> > + if (start >= (unsigned long)l1_stack_base && > >> >> > + start + len < (unsigned long)l1_stack_base + > >> >> > + l1_stack_len) > >> >> > + return 0; > >> >> > +#endif > >> >> > + > >> >> > >> >> > Does this need to have the #ifdef/stack check? or should we just > >> >> > allow scratchpad all the time? > >> >> > > >> >> I guess we can allow scratchpad all the time. Whether there is L1 stack > >> >> depends on applications, not kernel. > >> >> That means we will delete this configuration option and related > >> >> references. > >> >> > >> >> There is still a reason to keep APP_STACK_L1 option(L1 is shared by > >> >> application stack and exception stack): > >> > > >> > Thanks - that makes sense - How about: > >> > > >> > #ifndef CONFIG_EXCEPTION_L1_SCRATCH then? > >> > > >> > And (in theory) we should have the same in _access_ok - shouldn't we? > >> > It looks like only allow core B scratch? > >> > >> what about the next option that uses L1 scratch ? do we change every > >> location to check that define too ? > > > > I guess I thought the only thing that should preclude userspace from using > > L1 > > scratch (in any manner) is if the exception stack is there... > > > > Adding run time locking is a better way to do resource management (same way > > we > > do L1 data, or L1 instruction) than a compile time configuration. IMO > > which we have via the sram allocator, but the Kconfig option expands > into removing struct members and shrinking code
For scratch? I don't think any such thing exists, since scratchpad is only 4k. If you mean a single int in the kernel that keeps track of is L1_scratch being used or not, then -- yeah, it's worth it. (IHMO). > >> i think the current Kconfig keeps things cleanly separated according > >> to functionality. > > > > But that's the point - the next time someone wants to use L1 scratch for > > something - its a new Kconfig, rather than just telling the kernel they are > > going to use it, and not to let anyone else use it... (It would not be as > > flexible going forward). > > i dont have a problem with the Kconfig existing -- it provides clear > dependency handling in exactly 1 place. I guess I was thinking that there should only be two options: - userspace can use it - userspace shouldn't use it Two options is a single bool :) > i have a problem with the > #ifdef in the C code tying unrelated options together. the removal of > APP_STACK_L1 made Barry change all the ifdefs from the logical > binding: > > #ifdef CONFIG_APP_STACK_L1 > /* do stuff related to APP STACK L1 */ > #endf > > to the illogical binding: > #ifndef CONFIG_EXCEPTION_L1_SCRATCH > /* do stuff related to APP STACK L1 */ > #endif I guess I would think (and I might be wrong) that we want to get rid of those bindings.. /* if L1_scratch is avaliable - do stuff related to APP STACK L1 */ > so if we add another L1 scratch option, the C code would have to change to: > #if !defined(CONFIG_EXCEPTION_L1_SCRATCH) && > !defined(CONFIG_SOME_NEW_L1_SCRATCH_FEATURE) > /* do stuff related to APP STACK L1 */ > #endif No, it just does the same check if L1_scratch is avaliable. Just like the rest of L1 - what ever grabs it first - gets to use it. (which will be the kernel exception, if that is what the Kconfig says to do). _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
