On Tuesday 29 March 2011, Alan Cox wrote: > > The difference between the two is where you keep the common > > NFC logic: > > I think I'd disagree on that > > > > If you have a character device, it will be like a serial port > > connecting to a modem. Any higher-level protocols live in the > > user space and are limited to a single application then, which > > is required to have appropriate priviledges to open the device. > > A socket is just an API just as a file, you can put the stack in either > place in either case. Fair enough. Obviously the character device that we've been talking about here does not include the stack, but that would be another option. As you say, using a socket with a dumb interface is also possible, but that sounds to me like a combination of all the disadvantages. > > character device is its simplicity, so that would be preferred > > if you only expect a very small set of possible applications > > for this. > > NFC is not particularly performance dependant so having a lot of the > stack in a daemon isn't really going to hurt anything too much on a > client embedded device/phone. > > The bigger question is probably what it needs to look like the other end > - ie the server side embedded devices doing transactions. I was under the impression that NFC was peer-to-peer, so the driver would already be handling both sides potentially. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
