Pavel Pisa commented on a discussion on cpukit/dev/can/sja1000/sja1000.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1183#note_148166 > + "sja1000", > + irq_option, > + sja1000_interrupt, > + chip > + ); > + if ( sc != RTEMS_SUCCESSFUL ) { > + free( internal ); > + free( chip->qends_dev ); > + free( chip ); > + return NULL; > + } > + > + sc = rtems_task_create( > + rtems_build_name( 'C', 'A', 'N', 'S' ), > + worker_priority, > + RTEMS_MINIMUM_STACK_SIZE + 0x1000, Something like 512 or even 256 bytes should be enough. But my experience with stack allocated to small is really unpleasant. So I am for larger stack the firs and then reducing it when it is analyzed at runtime. Even better would be some check at link time. For non-recursive functions in threads and declared list of indirect calls it should be doable. Then the build should fail if some attribute reporting stack choice is too small for given build architecture. We can do some stress-testing on i386 and Zynq to have some values, but on x86_64 it can be different ad there is even red zone... So I would reduce to RTEMS_MINIMUM_STACK_SIZE + 1kB for example for now if you see 4 kB as too big waste and tune latter. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1183#note_148166 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
