Messages in this thread | | | Date | Fri, 09 Aug 2013 16:35:16 -0700 | From | Bob Smith <> | Subject | Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface |
| |
Greg Kroah-Hartman wrote: > Good protocols exist, look at protobufs from Google if you want to > define your own. Never create your own protocol these days, it doesn't > make sense, be it a text one or something else.
OK. I was using the term in the broader sense in which _meaning_ is assigned to the data in the protocol, not just the data marshaling.
> >> - a C _binding_ to present a C API and hide the protocol for C programmers, >> - a C++ binding and API for C++ programmers >> - a Java binding >> - a PHP binding >> - a Perl binding >> - a Python binding >> - a node.js binding >> - a Scratch binding for Raspberry Pi users >> - and some kind of shell binding for Bash programmers > All of those languages already support Linux syscalls, no need to create > anything else. Yes, we can publish the protocol and let the application writer deal with it. Bindings are nice only if you want to give a simple API to the developer or want to hide the details of the protocol.
> >> From a kernel developer's point of view the term "userspace driver" >> may seem like an oxymoron. By definition, all devices on the system >> have to be controlled by the kernel. All else is just userspace. > > Not true at all, I know all about userspace drivers, look at the UIO > code in the Linux kernel. It was created explicitly for this exact > thing, and to prevent the myrads of broken implementations from being > created again and again and again. Just use it if you wish to talk to > your hardware directly, lots of people do so. Well, not this exact thing. UIO is great if your hardware hangs on a bus directly connected to the CPU. It does nothing to help the case of hardware connected over some communications link.
> >> As an _opinion_ only, I think maybe userspace device drivers do exist. >> It refers to hardware that the kernel is not, and should not, be aware >> of. This hardware is not seen because it is at the end of some kind of >> communications channel like USB-serial or Ethernet. A developer might >> like to view that hardware as part of the overall system even if Linux >> and the CPU do not have direct access to it. A userspace driver looks >> something like this >> >> =(ProxyDevNode)====(daemon)===(CommChannel)===(hardware) > > Not really, you are just using an IPC to talk to a "real" device driver.
Yes, each of the "=" above has data passing through a real driver.
> > FPGAs are interesting things, people are creating "real" drivers for > them (see the linux-kernel archives for a few examples.) Other people > just use the UIO layer instead, which works quite well for them. I > suggest you do the same thing.
UIO can not see hardware at the end of a USB-serial link.
> > Again, you are creating a new form of userspace/userspace IPC, without a > good reason for why one of the existing IPC implementations will not > work for you (no, being able to use "echo" is not a good reason, you can > do that with local sockets just fine). > > I suggest you take a look at the book, The Linux Programming Interface, > by Michael Kerrisk, specifically chapter 43, which goes into great > detail about all of the existing IPC mechanisms that Linux already > provides. I'm sure one of them should be able to fit your needs.
Greg Kroah-Hartman wrote: > Otherwise, to accept this code, I need to see a way that normal users > can use it (i.e. no root or mknod), and that it can handle namespaces > and the security interface that the kernel has to support. To do so > otherwise would be unfair to users who expect such a thing.
OK, this makes sense.
thanks Bob Smith
| |