anchao commented on pull request #1346:
URL: https://github.com/apache/incubator-nuttx/pull/1346#issuecomment-652751672
I still do not understand why you should bypass kthread_create and use the
task_init/task_active interface directly,
Just for the interface design, the nxtask_ style should be a lower-level
interface and talk directly with task struct,
but for kernel developers should be to use kthread_, this is the correct way.
------------------
| kernel developer |
------------------
|
------------------
| kthread_create |
------------------
|
------------------
| task_init |
| task_active |
------------------
------------------
| Kernel Module | ----- Why?
------------------ |
|
------------------ |
| kthread_create | |
------------------ |
| |
------------------ |
| task_init |<-----
| task_active |
------------------
maybe you will say that we can implement kthread_init/kthread_active to
comply better our requirements,
but I do not think so beacuse which will increase the interface complexity,
which is not friendly.
In most cases, kernel developers do not need to care about what happens
inside the TASK,
developers do not care about what is "tcb", what is "ttcb", what is "task
type",
Do you want every kernel module with special requirements for tasks to
complete such complex implementation?
```
static int nxthread_create(FAR const char *name, uint8_t ttype, int priority,
FAR void *stack, int stack_size, main_t entry,
FAR char * const argv[])
{
FAR struct task_tcb_s *tcb;
pid_t pid;
int ret;
/* Allocate a TCB for the new task. */
tcb = (FAR struct task_tcb_s *)kmm_zalloc(sizeof(struct task_tcb_s));
if (!tcb)
{
serr("ERROR: Failed to allocate TCB\n");
return -ENOMEM;
}
/* Setup the task type */
tcb->cmn.flags = ttype;
/* Initialize the task */
ret = nxtask_init(tcb, name, priority, stack, stack_size, entry, argv);
if (ret < OK)
{
kmm_free(tcb);
return ret;
}
/* Get the assigned pid before we start the task */
pid = tcb->cmn.pid;
/* Activate the task */
nxtask_activate(&tcb->cmn);
return (int)pid;
}
```
> Not only does this change duplicate existing functionality, but subverts a
common OS internal interface to support special operations used on by Xiaomi
and not for any other users. Subverting the OS for your own personal business
development is not an acceptable practice.
Please don't always speculate on our intention, our goal is consistent, In
order to make nuttx better, we have been still hard to enhancing nuttx's
compatibility, ease-using and reducing unnecessary coupling
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]