Emulate errors that we have on physical rasp within virtual rasp

[flongo82]

When dealing with GPIO pins on top of a physical rasp, user can experience certain issues, e.g.,:

• if physical pin is already exported and we try to export it again, we get "Device is busy" error;
• if we try to export a pin that does not exist, we get a different error.

We should emulate the same errors inside a virtual rasp. An experienced user should not be able to distinguish a physical rasp from a virtual one when dealing with GPIO pins.

[maratstepanov]

Currently I have a big issue with this, and don't know how to overcome yet.
For example, during "write" syscall, we intercept it and perform different actions, including the ones which perform new syscalls (for example creating /gpio_mnt/${name}/sys/devices/platform/soc/3f200000.gpio/gpio/gpio${inputstring}). And if we did not perfrom call of cb(result) yet, node.js hangs. I think, new syscall is blocked by old one (which did not answer yet).
If I put cb(result) to the point where we did not perform any new syscalls yet, in works just fine. And this is what it did.
If we want to simulate errors, we need to put cb(result) after performing checks, which actually include new syscalls.
Maybe you know how to overcome this. I'm seeking, but no success yet.
If we don't find how to overcome, we can try avoiding new syscalls before cb(result) and find other ways to perform checks etc, but this is a challenge too.

[flongo82]

I did not get exactly what is the problem here. Maybe we should go for a skype call about this.

[flongo82]

Can you please perform an analysis of the different error messages/events that can happen when dealing with GPIO pins and put it here. This way, we can have an idea of what it is really necessary.

However, I would say that this issue can be considered low-priority.