mkfifo works only in '/dev/' directory.

[pholat]

When I was trying to create FIFO somewhere other it failed, I could only open normal file there. Only when checking examples I saw that these uses /dev/ directory.

I had issues with AF_UNIX sockets too, afair I could open it, but couldn't make any data transfer. As I was checking internal sockets tests were made on loopback interface, which I don't consider a good practice - which is why FIFO is in use.

[sunghan-chang]

@samirsahu1947 Here is no activity. Please check this issue asap.

[sunghan-chang]

@pholat I heard our network stack, lwip, does not support AF_UNIX. When we upgrade lwip version to 2.0.2, we removed AF_UNIX definition. Sorry for confusing.
And file system engineer will give reponse about FIFO.

[pholat]

@sunghan-chang Thanks for confirmation, I actually lost quite a bit of time wondering why it worked different on Artik then in tests.

I could only suggest that it would be nice if sub-repositories could be handled as git submodules - it would be easier to check different versions of them.

[sunghan-chang]

@pholat Do you mean arch for artik?

[pradeepns85]

@pholat , In TizenRT, unlike linux, mkfifo is created as device driver file and not a special file type. It's a device driver instance. while creating the device driver file, it does not allow to create a device file inside any mount partition.

Flow => mkfifo-> register_driver -> inode_reserve -> inode_search

inode_reserve()
{

200 if (inode_search(&name, &left, &parent, (FAR const char *)NULL) != NULL) {
201 / It is an error if the node already exists in the tree. */
202
203 return -EEXIST; => Returns failure as it's a mountpoint file type
204 }

}

inode_search()
{

327 if (!name || INODE_IS_MOUNTPT(node)) {
328 / Either (1) we are at the end of the path, so this must be the
329 * node we are looking for or else (2) this node is a mountpoint
330 * and will handle the remaining part of the pathname
331 */
332
333 if (relpath) {
334 *relpath = name;
335 }
336 break;
337 } else {

371 return node;

}

Since it's a device driver file instance, We can use mkfifo to create file in any other pseudo file paths . for ex

/tmp/fifo
/fifo
/dev/fifo
etc

[pholat]

@sunghan-chang I've checked it on artik053s
@pradeepns85 os/include/sys/stat.h only states that mkfifo(..) is a POSIX api and follows pubs.opengroup.org, therefore comes the assumption that if you can provide (any) path, like in referenced Linux example - as standard doesn't specify memory mapping scenario.
As it's not quite the case it would be nice to add it to the cited header for future reference - to know that without reading whole implementation :)

Btw. thanks for explanation.