Will there be node bindings for calling the new functions like uv_device_ioctl?

Will there be node bindings for calling the new functions like uv_device_ioctl?

That's up to Node, this is libuv.

Mind adding something to docs/? :)

Sorry for showing my ignorance, but is rs232 the kind of serial protocol used to talk to things like arduinos?

Also for what it's worth, chrome apps have had s serial API for some time that's used by various apps to talk to hardware devices. https://developer.chrome.com/apps/serial. I mention this because it's a cross-platform API that could help guide what features libuv wants to tacke. We obviously don't need all the annoying security sandbox features and can keep our existing stream APIs though.

@creationix Thanks for the link, I'll take a look. Hopefully now that 1.7 is out I can review this thorougly soon.

Currently this patch only exposes the minimum components for device communication: opening, reading, writing and a generic ioctl mechanism, applications would use platform specific ioctls to change parameters such as baud rate. Note that this can also be used to open devices such as /dev/tun.

Right, I see use in both a low-level system interface that require users to write platform specific code and a cross-platform high-level serial interface that is less capable, but works cross-platform for a specific use case.

I've gone down this road before with luvit and the problem with just exposing ioctl when pairing libuv with a scripting language is that the scripting language doesn't have access to system headers (macros and constants) to know which ioctls to use.

Maybe the burden of the cross-platform ioctl part should live between libuv and the scripting language (luvi in my case). Libuv would provide the minimal bits to call ioctls on uv device streams and the C code using it would be responsible for the rest. But the API exposed to the scripting language would look more like the chrome.serial API.

Maybe the burden of the cross-platform ioctl part should live between libuv and the scripting language (luvi in my case). Libuv would provide the minimal bits to call ioctls on uv device streams and the C code using it would be responsible for the rest. But the API exposed to the scripting language would look more like the chrome.serial API.

This sounds like a good idea to me!

It would be really cool if there was a collection of libuv addons that handled this in a generic way independent of the vm being used. Then node, pyuv and luvit can share the serial module that lives between libuv and the vm.

sorry for close this, because I need to keep step with v1.x, so I create a branch for device at https://github.com/zhaozg/libuv/tree/device

Now #484