From: Lars-Peter Clausen <lars@metafoo.de>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-iio@vger.kernel.org, Michael.Hennerich@analog.com,
device-drivers-devel@blackfin.uclinux.org
Subject: Re: [PATCH] staging:iio: header reorganization
Date: Fri, 21 Oct 2011 12:42:15 +0200 [thread overview]
Message-ID: <4EA14C87.2020606@metafoo.de> (raw)
In-Reply-To: <1319188148-32349-1-git-send-email-jic23@cam.ac.uk>
On 10/21/2011 11:09 AM, Jonathan Cameron wrote:
> Issue brought up by Lars-Peter Clausen. This is a varient of what
> he suggested.
>
> io/iio.h for driver stuff (has to include types.h)
> Sub files for the bits drivers may or may not use
> iio/sysfs.h
> iio/buffer.h (contents of current buffer_generic.h)
> (obviously anything offering events will need events.h as well)
> iio/types.h for the enums that matter to both
> iio_chan_type, iio_modifier
> iio/events.h for the event code stuff
> IIO_EVENT_CODE and friends. + everything in chrdev.h So this
> is the stuff that userspace cares about.
> Also include iio_event_type, iio_event_direction
>
> Thus iio drivers include iio.h + as required
> events.h
> sysfs.h
> buffer.h
>
> in kernel users (once that interface is merged) will need inkern.h
> which will pull in types.h
>
> Userspace will need just events.h (which pulls in types.h) to get
> everything they need to know about. Buffer userspace access doesn't
> currently need any core defines. All information about the data
> format is passed through sysfs.
This seems to work nicely, thanks. There two minor issues left, but those
were also present before the restructuring, I'll send patches shortly.
Another issue is that you can only open the iio character device if your
device has buffer support, so without buffer support no event support
either. Michael said that has been some discussion on this before, do you
remember the conclusions of that discussion?
> [...]
> --- /dev/null
> +++ b/drivers/staging/iio/events.h
> @@ -0,0 +1,71 @@
> +/* The industrial I/O - event passing to userspace
> + *
> + * Copyright (c) 2008-2011 Jonathan Cameron
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + */
> +#include "types.h"
Any specific reason why you put this include above the include guard?
> +
> +#ifndef _IIO_EVENTS_H_
> +#define _IIO_EVENTS_H_
> +
> [...]
> diff --git a/drivers/staging/iio/iio.h b/drivers/staging/iio/iio.h
> index 429589f..339b609 100644
> --- a/drivers/staging/iio/iio.h
> +++ b/drivers/staging/iio/iio.h
> @@ -7,7 +7,7 @@
> * under the terms of the GNU General Public License version 2 as published by
> * the Free Software Foundation.
> */
> -
> +#include "types.h"
Same here
> #ifndef _INDUSTRIAL_IO_H_
> #define _INDUSTRIAL_IO_H_
> [...]
next prev parent reply other threads:[~2011-10-21 10:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-21 7:21 Userspace event handling and header files Lars-Peter Clausen
2011-10-21 8:02 ` Hennerich, Michael
2011-10-21 8:58 ` Jonathan Cameron
2011-10-21 9:09 ` [PATCH] staging:iio: header reorganization Jonathan Cameron
2011-10-21 9:12 ` Jonathan Cameron
2011-10-21 9:28 ` Jonathan Cameron
2011-10-21 10:42 ` Lars-Peter Clausen [this message]
2011-10-21 10:59 ` Jonathan Cameron
2011-10-21 11:15 ` Jonathan Cameron
2011-10-21 10:59 ` [PATCH 1/2] staging:iio: Add missing ioctl.h include to events.h Lars-Peter Clausen
2011-10-21 10:59 ` [PATCH 2/2] staging:iio: Use userspace types for iio_event_data Lars-Peter Clausen
2011-10-21 11:39 ` Jonathan Cameron
2011-10-21 11:00 ` [PATCH 1/2] staging:iio: Add missing ioctl.h include to events.h Jonathan Cameron
2011-10-21 9:42 ` Userspace event handling and header files Lars-Peter Clausen
2011-10-21 9:44 ` Jonathan Cameron
2011-10-21 9:51 ` Jonathan Cameron
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=4EA14C87.2020606@metafoo.de \
--to=lars@metafoo.de \
--cc=Michael.Hennerich@analog.com \
--cc=device-drivers-devel@blackfin.uclinux.org \
--cc=jic23@cam.ac.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).