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 >> 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 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 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 -mike _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
