Topic: daemon suggestion - user access to devices via IPC

One issue is that user level programs do not have general device access through libusb on Solaris and Linux.

I propose that libnfc is re-architected to be able to be a daemon which runs as root with a library ( called libnfc... ) which provides user programs with access to the daemon using IPC ( eg unix domain sockets ).

So just like PCSClite has "libpcsclite..." and "pcscd", libnfc should have "libnfc....." and "nfcd".

This could be implemented by

(a) defining a byte code protocol to go between libnfc and nfcd

(b) building nfcd as a program that implements the server side and links to the code we currently consider the source to libnfc.

(c) build a new shim libnfc which exports the current API but connects to and acts as a client to nfcd using the defined byte code from (a).

Platforms such as Windows and MacOSX don't need this deamon because libusb-win32 and IOkit both provide user level access.

Thoughts?

Last edited by snapdev (2010-07-25 16:20:31)

Re: daemon suggestion - user access to devices via IPC

Hello,

snapdev wrote:

One issue is that user level programs do not have general device access through libusb on Solaris and Linux.

In source root directory, you can found "pn53x.rules" to put in " /etc/udev/rules.d" to set "plugdev" group access to usb devices. It works fine and its daily use here on a GNU/linux.
For FreeBSD, there is a simalar file ("pn53x.conf") for devd.

snapdev wrote:

I propose that libnfc is re-architected to be able to be a daemon which runs as root with a library ( called libnfc... ) which provides user programs with access to the daemon using IPC ( eg unix domain sockets ).

There is a similar concept behind the NFCd project hosted at http://nfc-tools.googlecode.com, that use D-Bus to handle tags from userland with very high content access in mind (i.e. don't need to know about modulation, parity, blocks, etc.)

snapdev wrote:

So just like PCSClite has "libpcsclite..." and "pcscd", libnfc should have "libnfc....." and "nfcd".

It could also be interesting to use PCSC directly, using:
http://www.libnfc.org/community/topic/1 … c-devices/

BTW, arguments and suggestions like this are very welcome.

Romuald Conty