From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Bob Smith <bsmith@linuxtoys.org>
Cc: Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface
Date: Fri, 9 Aug 2013 16:46:29 -0700 [thread overview]
Message-ID: <20130809234629.GA16866@kroah.com> (raw)
In-Reply-To: <52057CB4.2020603@linuxtoys.org>
On Fri, Aug 09, 2013 at 04:35:16PM -0700, Bob Smith wrote:
> 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.
Again, protobufs are a great way to define the meaning of the protocol
in a manner that is descriptive, fast, versioned, discoverable, and best
of all for you, with bindings for all languages :)
> >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.
Like PCI? :)
Actually, I'm not kidding about that, I have a PCI bus here that is
across a flexible cable that can dynamically be plugged and unplugged
from a machine at any point in time using a communications link. It's
called Thunderbolt today, but has been called ExpressBus, and lots of
other names in the past.
> >>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.
No it doesn't. A "real" driver talks to hardware. You only have that
for the last "===".
> >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.
Nor should it ever be used for something like that. There is a protocol
for this device that the kernel exposes, use it :)
thanks,
greg k-h
next prev parent reply other threads:[~2013-08-09 23:46 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51FC5478.40500@linuxtoys.org>
2013-08-03 1:19 ` [PATCH 001/001] CHAR DRIVERS: a simple device to give daemons a /sys-like interface Bob Smith
2013-08-03 1:56 ` Joe Perches
2013-08-03 2:35 ` Greg Kroah-Hartman
2013-08-03 18:12 ` Bob Smith
2013-08-03 22:38 ` Greg Kroah-Hartman
2013-08-04 21:54 ` Bob Smith
2013-08-04 23:19 ` Greg Kroah-Hartman
2013-08-05 23:46 ` Bob Smith
2013-08-06 9:46 ` Greg Kroah-Hartman
2013-08-07 19:02 ` Bob Smith
2013-08-07 19:27 ` Greg Kroah-Hartman
2013-08-07 19:39 ` Bob Smith
2013-08-07 19:51 ` Greg Kroah-Hartman
2013-08-07 19:54 ` Greg Kroah-Hartman
2013-08-07 21:04 ` Bob Smith
2013-08-07 21:33 ` Greg Kroah-Hartman
2013-08-08 21:23 ` Bob Smith
2013-08-09 21:52 ` Greg Kroah-Hartman
2013-08-09 22:20 ` Bob Smith
2013-08-09 22:14 ` Bob Smith
2013-08-09 23:01 ` Greg Kroah-Hartman
2013-08-09 23:35 ` Bob Smith
2013-08-09 23:46 ` Greg Kroah-Hartman [this message]
2013-08-10 20:08 ` Bob Smith
2013-08-10 20:29 ` richard -rw- weinberger
2013-08-10 20:49 ` Bob Smith
2013-08-10 21:43 ` Arnd Bergmann
2013-08-10 22:07 ` Bob Smith
2013-08-13 20:15 ` Arnd Bergmann
2013-08-07 21:28 ` Bob Smith
2013-08-07 21:40 ` Greg Kroah-Hartman
2013-08-07 21:53 ` Bob Smith
2013-08-09 21:54 ` Greg Kroah-Hartman
2013-08-09 22:51 ` Bob Smith
2013-08-09 23:04 ` Greg Kroah-Hartman
2013-08-07 21:38 ` Bob Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130809234629.GA16866@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=bsmith@linuxtoys.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.