From: "Getz, Robin" <robin.getz@analog.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Jonathan Cameron <jic23@cam.ac.uk>,
"Clausen, Lars-Peter" <Lars-Peter.Clausen@analog.com>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Subject: Re: Userspace libs
Date: Mon, 18 Feb 2013 15:15:35 -0500 [thread overview]
Message-ID: <201302181515.36379.robin.getz@analog.com> (raw)
In-Reply-To: <511F7FA5.7060805@kernel.org>
On Sat 16 Feb 2013 07:46, Jonathan Cameron pondered:
> On 02/13/2013 07:12 PM, Getz, Robin wrote:
> > Jonathan:
[snip]
> > I would like to re-write some of the existing iio-utils.h (so iio device
> > context is managed by the application), to become a little more thread
> > friendly, and also merge in some of the networking piece - so when using
> > a headless embedded device - userspace doesn't need to change/manage
> > things much.
>
> All the above looks good and it is very nice to have some non trivial
> userspace support. I'll be happy to see any updates/cleanups to iio-utils.h
> but keep in mind that it is only really meant to be a trivial in kernel
> tree example.
is there any performance metrics that we want the in-tree version to hit?
The existing versions are certainly slim on memory, but use malloc, which may
cause memory leaks if the person on the application side isn't careful
freeing things, or cause performance issues, or just cause plain failures in
low memory embedded systems...
> The original plan was to have a separately maintained
> userspace library to do things 'properly'.
Where was this suppost to live?
> I guess it depends on exactly what changes you are thinking of.
There are some features which we use to "self-discover" the installed
devices/drivers.
return a string of names
handle unsigned ints in the read/write functions
Some minor stuff.
> The networking stuff in particular
> might introduce some non kernel dependencies that may or may not be a
> problem.
Ack - I think that sits beside yours. iio_utils_attach.h and the network one
is iio_utils_net.h (ot something like that). It's the same structures,
similar function names, it's does it include a IP address, or a path...
> > Is there a list of other things people want to see from userspace? [2]
>
> Nope. Probably should be though. Well volunteered!
> Right now we don't really have a clean list of what people want on the
> kernel side, just a lot of randomly scattered mailing list threads.
Any in specific stand out?
> >
> > [1] Which reminds me - is this planned on moving out
> > of ./drivres/staging/iio/Documentation into ./Documentation/iio ?
>
> err. Yes. Keep forgetting to do it. Ah well next cycle ;)
> Lots of stuff still to move in general.
Thanks.
> > [2] I have been going through:
> > - zio-dump http://www.ohwr.org/projects/zio/wiki/Readme
> > - Comedilib various
> > ?
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-02-18 20:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 19:12 Userspace libs Getz, Robin
2013-02-16 12:46 ` Jonathan Cameron
2013-02-18 20:15 ` Getz, Robin [this message]
2013-02-19 8:38 ` Manuel Stahl
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=201302181515.36379.robin.getz@analog.com \
--to=robin.getz@analog.com \
--cc=Lars-Peter.Clausen@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=jic23@cam.ac.uk \
--cc=jic23@kernel.org \
--cc=linux-iio@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.