>
> Any static should be conditioned on CONFIG_LIB_SYSCALL for the
> task_spawn() version in sched/task/task_spawn.c, however, that is not
> really necessary either because that version is not linked into the same
> binary as is the version in libs/libc/spawn.
>
> I suppose a user could enable CONFIG_LIB_SYSCALL in a FLAT build.  Then
> both would be linked into the same blob, but that is kind of a useless
> configuration.

Yes, this is what my current config has.

I am trying to port my cRTOS design to newer nuttx.

While running in FLAT build, I load Linux binaries in SystemV ABI and
hook the system calls redirect them to Nuttx APIs.

Of course, I can do this in a kernel build, but I want to keep things simple.

I agree that using system calls in a FLAT build is quite meaning less.

However, I think we can somehow keep this flexibility for exploiting
for binary compability?

-- 
Yang

2020年5月31日(日) 1:07 Gregory Nutt <spudan...@gmail.com>:
>
>
> > Any static should be conditioned on CONFIG_LIB_SYSCALL for the
> > task_spawn() version in sched/task/task_spawn.c, however, that is not
> > really necessary either because that version is not linked into the
> > same binary as is the version in libs/libc/spawn.
> >
> > I suppose a user could enable CONFIG_LIB_SYSCALL in a FLAT build.
> > Then both would be linked into the same blob, but that is kind of a
> > useless configuration.
> >
> So, I think the preferred fix would simply to make CONFIG_LIB_SYSCALL
> dependent on !CONFIG_BUILD_FLAT in the Kconfig file.
>
>


-- 
Yang Chung Fan (楊宗凡) (ヤン ゾン ファン)
Member of Softlab, Tsukuba University , Japan
Email: sonic.tw...@gmail.com

Reply via email to