All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: Alexandru Ardelean <alexandru.ardelean@analog.com>,
	linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org,
	lars@metafoo.de, Michael.Hennerich@analog.com,
	nuno.sa@analog.com, dragos.bogdan@analog.com,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v2 03/12][RESEND] iio: buffer: rework buffer & scan_elements dir creation
Date: Mon, 25 Jan 2021 20:28:17 +0100	[thread overview]
Message-ID: <YA8b0az9c0Hha405@kroah.com> (raw)
In-Reply-To: <20210124181126.07c100a5@archlinux>

On Sun, Jan 24, 2021 at 06:11:26PM +0000, Jonathan Cameron wrote:
> On Fri, 22 Jan 2021 18:25:20 +0200
> Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
> 
> > When adding more than one IIO buffer per IIO device, we will need to create
> > a buffer & scan_elements directory for each buffer.
> > We also want to move the 'scan_elements' to be a sub-directory of the
> > 'buffer' folder.
> > 
> > The format we want to reach is, for a iio:device0 folder, for 2 buffers
> > [for example], we have a 'buffer0' and a 'buffer1' subfolder, and each with
> > it's own 'scan_elements' subfolder.
> > 
> > So, for example:
> >    iio:device0/buffer0
> >       scan_elements/
> > 
> >    iio:device0/buffer1
> >       scan_elements/
> > 
> > The other attributes under 'bufferX' would remain unchanged.
> > 
> > However, we would also need to symlink back to the old 'buffer' &
> > 'scan_elements' folders, to keep backwards compatibility.
> > 
> > Doing all these, require that we maintain the kobjects for each 'bufferX'
> > and 'scan_elements' so that we can symlink them back. We also need to
> > implement the sysfs_ops for these folders.
> > 
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> 
> +CC GregKH and Rafael W for feedback on various things inline.
> 
> It might be that this is the neatest solution that we can come up with but
> more eyes would be good!

In short, please do NOT do this.

At all.

no.

{sigh}

> 
> Whilst I think this looks fine, I'm less confident than I'd like to be.
> 
> Jonathan
> 
> > ---
> >  drivers/iio/industrialio-buffer.c | 195 +++++++++++++++++++++++++++---
> >  drivers/iio/industrialio-core.c   |  24 ++--
> >  include/linux/iio/buffer_impl.h   |  14 ++-
> >  include/linux/iio/iio.h           |   2 +-
> >  4 files changed, 200 insertions(+), 35 deletions(-)
> > 
> > diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c
> > index 0412c4fda4c1..0f470d902790 100644
> > --- a/drivers/iio/industrialio-buffer.c
> > +++ b/drivers/iio/industrialio-buffer.c
> > @@ -1175,8 +1175,6 @@ static ssize_t iio_buffer_store_enable(struct device *dev,
> >  	return (ret < 0) ? ret : len;
> >  }
> >  
> > -static const char * const iio_scan_elements_group_name = "scan_elements";
> > -
> >  static ssize_t iio_buffer_show_watermark(struct device *dev,
> >  					 struct device_attribute *attr,
> >  					 char *buf)
> > @@ -1252,6 +1250,124 @@ static struct attribute *iio_buffer_attrs[] = {
> >  	&dev_attr_data_available.attr,
> >  };
> >  
> > +#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)
> > +
> > +static ssize_t iio_buffer_dir_attr_show(struct kobject *kobj,
> > +					struct attribute *attr,
> > +					char *buf)
> > +{
> > +	struct iio_buffer *buffer = container_of(kobj, struct iio_buffer, buffer_dir);
> > +	struct device_attribute *dattr;
> > +
> > +	dattr = to_dev_attr(attr);
> > +
> > +	return dattr->show(&buffer->indio_dev->dev, dattr, buf);
> > +}


First off, you are dealing with "raw" kobjects here, below a 'struct
device' in the device tree, which means that suddenly userspace does not
know what in the world is going on, and you lost events and lots of
other stuff.

Never do this.  It should not be needed, and you are just trying to
paper over one odd decision of an api with another one you will be stuck
with for forever.

Remember the driver core can create subdirectories for your attributes
automatically if you want them to be in a subdir, but that's it, no
further than that.  Just name the attribute group.

But yes, you can not create a symlink to there, because (surprise), you
don't want to!

So please, just rethink your naming, create a totally new naming scheme
for multiple entities, and just drop the old one (or keep a single
value if you really want to.)  Don't make it harder than it has to be
please, you can never remove the "compatible symlinks", just make a new
api and move on.

thanks,

greg k-h

  parent reply	other threads:[~2021-01-25 19:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22 16:25 [PATCH v2 00/12][RESEND] iio: core,buffer: add support for multiple IIO buffers per IIO device Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 01/12][RESEND] iio: core: register chardev only if needed Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 02/12][RESEND] iio: buffer: add back-ref from iio_buffer to iio_dev Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 03/12][RESEND] iio: buffer: rework buffer & scan_elements dir creation Alexandru Ardelean
2021-01-24 18:11   ` Jonathan Cameron
2021-01-24 19:07     ` Alexandru Ardelean
2021-01-25 19:29       ` Greg Kroah-Hartman
2021-01-25 19:28     ` Greg Kroah-Hartman [this message]
2021-01-26  9:45       ` Alexandru Ardelean
2021-01-27 14:48         ` Jonathan Cameron
2021-01-22 16:25 ` [PATCH v2 04/12][RESEND] iio: buffer: add index to the first IIO buffer dir and symlink it back Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 05/12][RESEND] iio: core: split __iio_device_attr_init() to init only the attr object Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 06/12][RESEND] iio: buffer: re-route scan_elements via it's kobj_type Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 07/12][RESEND] iio: buffer: re-route core buffer attributes via it's new kobj_type Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 08/12][RESEND] iio: buffer: add helper to get the IIO device to which a buffer belongs Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 09/12][RESEND] iio: re-route all buffer attributes through new buffer kobj_type Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 10/12][RESEND] iio: core: wrap iio device & buffer into struct for character devices Alexandru Ardelean
2021-01-22 16:25 ` [PATCH v2 11/12][RESEND] iio: buffer: introduce support for attaching more IIO buffers Alexandru Ardelean
2021-01-25 11:06   ` [kbuild] " Dan Carpenter
2021-01-25 11:06     ` Dan Carpenter
2021-01-25 11:06     ` Dan Carpenter
2021-01-22 16:25 ` [PATCH v2 12/12][RESEND] iio: buffer: add ioctl() to support opening extra buffers for IIO device Alexandru Ardelean
2021-01-24 18:38   ` Jonathan Cameron
2021-01-24 19:32     ` Alexandru Ardelean

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=YA8b0az9c0Hha405@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=alexandru.ardelean@analog.com \
    --cc=dragos.bogdan@analog.com \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.com \
    --cc=rafael@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.