All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: "Guzman Lugo, Fernando" <fernando.lugo@ti.com>,
	"gregkh@suse.de" <gregkh@suse.de>,
	"hiroshi.doyu@nokia.com" <hiroshi.doyu@nokia.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Felipe Contreras <felipe.contreras@nokia.com>,
	"andy.shevchenko@gmail.com" <andy.shevchenko@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map
Date: Thu, 28 Oct 2010 16:56:35 +0100	[thread overview]
Message-ID: <20101028155635.GF3122@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTimwbNV227yhPy-5E5rdAL2LciKeCSouWGW9H+WG@mail.gmail.com>

On Wed, Oct 27, 2010 at 11:19:47AM +0300, Felipe Contreras wrote:
> Yes, but this has to be done on every library/app that is using the dsp.
> It's much easier to do it on kernel side.
> 
> Besides, at least on gst-dsp we want it to work for _all_ bridge
> versions, so it would be:
> 
> @@ -829,7 +829,9 @@ struct map_mem {
>         void *proc_handle;
>         void *mpu_addr;
>         unsigned long size;
> +#if DSP_API >= 3
>         void *req_addr;
> +#endif
>         void **ret_map_addr;
>         unsigned long attr;
>  };

This thread is getting really stupid.  There is a process for changing
the arguments to ioctl.

The first thing is that ioctl numbers are supposed to be defined in a
standard form - using _IO(), _IOR(), _IOW() and _IOWR().  Amongst the
things that these macros take is the structure which is being passed.

What this means is that the ioctl number generated by these macros is
directly related to the size of the structure.  This immediately gives
a way to deal with a limited set of changes to the structure.

The steps are as follows:

1. Rename the structure and all uses of it from "struct map_mem" to
   "struct old_map_mem"
2. Rename the ioctl definition names and all uses to have an OLD prefix.

So at this stage, the original ioctl number and structure are still
present, and importantly are unchanged except by name.

3. Add the new "struct map_mem".
4. Add the new ioctl name definition using "struct map_mem" to identify
   it.
5. Implement the new ioctl number.  Optionally, implement the old ioctl
   functionality via the new implementation if this is appropriate - but
   make sure that the old ioctl still works.
6. arrange for users of the old ioctl to receive a warning that it's
   deprecated.

This allows existing userspace to continue working, but with warnings so
that people know that they need to rebuild their libraries against the
new structures.

There's no need for a DSP_API define using this method, provided you
don't end up with these structures shrinking and then re-growing back
to a size that they were before.

WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map
Date: Thu, 28 Oct 2010 16:56:35 +0100	[thread overview]
Message-ID: <20101028155635.GF3122@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <AANLkTimwbNV227yhPy-5E5rdAL2LciKeCSouWGW9H+WG@mail.gmail.com>

On Wed, Oct 27, 2010 at 11:19:47AM +0300, Felipe Contreras wrote:
> Yes, but this has to be done on every library/app that is using the dsp.
> It's much easier to do it on kernel side.
> 
> Besides, at least on gst-dsp we want it to work for _all_ bridge
> versions, so it would be:
> 
> @@ -829,7 +829,9 @@ struct map_mem {
>         void *proc_handle;
>         void *mpu_addr;
>         unsigned long size;
> +#if DSP_API >= 3
>         void *req_addr;
> +#endif
>         void **ret_map_addr;
>         unsigned long attr;
>  };

This thread is getting really stupid.  There is a process for changing
the arguments to ioctl.

The first thing is that ioctl numbers are supposed to be defined in a
standard form - using _IO(), _IOR(), _IOW() and _IOWR().  Amongst the
things that these macros take is the structure which is being passed.

What this means is that the ioctl number generated by these macros is
directly related to the size of the structure.  This immediately gives
a way to deal with a limited set of changes to the structure.

The steps are as follows:

1. Rename the structure and all uses of it from "struct map_mem" to
   "struct old_map_mem"
2. Rename the ioctl definition names and all uses to have an OLD prefix.

So at this stage, the original ioctl number and structure are still
present, and importantly are unchanged except by name.

3. Add the new "struct map_mem".
4. Add the new ioctl name definition using "struct map_mem" to identify
   it.
5. Implement the new ioctl number.  Optionally, implement the old ioctl
   functionality via the new implementation if this is appropriate - but
   make sure that the old ioctl still works.
6. arrange for users of the old ioctl to receive a warning that it's
   deprecated.

This allows existing userspace to continue working, but with warnings so
that people know that they need to rebuild their libraries against the
new structures.

There's no need for a DSP_API define using this method, provided you
don't end up with these structures shrinking and then re-growing back
to a size that they were before.

  parent reply	other threads:[~2010-10-28 15:57 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-26  0:51 [PATCH 0/8] staging: tidspbridge - misc fixes Fernando Guzman Lugo
2010-10-26  0:51 ` Fernando Guzman Lugo
2010-10-26  0:51 ` Fernando Guzman Lugo
2010-10-26  0:51 ` [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Fernando Guzman Lugo
2010-10-26  0:51   ` Fernando Guzman Lugo
2010-10-26  0:51   ` Fernando Guzman Lugo
2010-10-26  0:51   ` [PATCH 2/8] staging: tidspbridge - add kconfig parameter for DMM size Fernando Guzman Lugo
2010-10-26  0:51     ` Fernando Guzman Lugo
2010-10-26  0:51     ` Fernando Guzman Lugo
2010-10-26  0:51     ` [PATCH 3/8] staging: tidspbridge - change mmufault tasklet to a workqueue Fernando Guzman Lugo
2010-10-26  0:51       ` Fernando Guzman Lugo
2010-10-26  0:51       ` Fernando Guzman Lugo
2010-10-26  0:51       ` [PATCH 4/8] staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow Fernando Guzman Lugo
2010-10-26  0:51         ` Fernando Guzman Lugo
2010-10-26  0:51         ` Fernando Guzman Lugo
2010-10-26  0:51         ` [PATCH 5/8] staging: tidspbridge - use GTP7 for DSP stack dump Fernando Guzman Lugo
2010-10-26  0:51           ` Fernando Guzman Lugo
2010-10-26  0:51           ` Fernando Guzman Lugo
2010-10-26  0:51           ` [PATCH 6/8] staging: tidspbridge - remove disabling twl when printing DSP stack Fernando Guzman Lugo
2010-10-26  0:51             ` Fernando Guzman Lugo
2010-10-26  0:51             ` Fernando Guzman Lugo
2010-10-26  0:51             ` [PATCH 7/8] staging: tidspbridge - fix some issues after iommu patches Fernando Guzman Lugo
2010-10-26  0:51               ` Fernando Guzman Lugo
2010-10-26  0:51               ` Fernando Guzman Lugo
2010-10-26  0:51               ` [PATCH 8/8] staging: tidspbridge - make sync_wait_on_event interruptible Fernando Guzman Lugo
2010-10-26  0:51                 ` Fernando Guzman Lugo
2010-10-26  0:51                 ` Fernando Guzman Lugo
2010-10-26  0:58                 ` Felipe Contreras
2010-10-26  0:58                   ` Felipe Contreras
2010-10-26 15:50                   ` Guzman Lugo, Fernando
2010-10-26 15:50                     ` Guzman Lugo, Fernando
2010-10-26 15:50                     ` Guzman Lugo, Fernando
2010-10-26 17:03                     ` Felipe Contreras
2010-10-26 17:03                       ` Felipe Contreras
2010-10-26 17:58                       ` Guzman Lugo, Fernando
2010-10-26 17:58                         ` Guzman Lugo, Fernando
2010-10-26 17:58                         ` Guzman Lugo, Fernando
2010-10-26 19:27                         ` Felipe Contreras
2010-10-26 19:27                           ` Felipe Contreras
2010-10-26 20:01                           ` Guzman Lugo, Fernando
2010-10-26 20:01                             ` Guzman Lugo, Fernando
2010-10-26 20:01                             ` Guzman Lugo, Fernando
2010-12-06  8:51                   ` Ramirez Luna, Omar
2010-12-06  8:51                     ` Ramirez Luna, Omar
2010-10-26 11:46   ` [PATCH 1/8] staging: tidspbridge - remove req_addr from proc_map Felipe Contreras
2010-10-26 11:46     ` Felipe Contreras
2010-10-26 15:52     ` Guzman Lugo, Fernando
2010-10-26 15:52       ` Guzman Lugo, Fernando
2010-10-26 15:52       ` Guzman Lugo, Fernando
2010-10-26 17:07       ` Felipe Contreras
2010-10-26 17:07         ` Felipe Contreras
2010-10-26 18:08         ` Guzman Lugo, Fernando
2010-10-26 18:08           ` Guzman Lugo, Fernando
2010-10-26 18:08           ` Guzman Lugo, Fernando
2010-10-26 19:37           ` Felipe Contreras
2010-10-26 19:37             ` Felipe Contreras
2010-10-26 20:39             ` Guzman Lugo, Fernando
2010-10-26 20:39               ` Guzman Lugo, Fernando
2010-10-26 20:39               ` Guzman Lugo, Fernando
2010-10-27  8:19               ` Felipe Contreras
2010-10-27  8:19                 ` Felipe Contreras
2010-10-27  8:19                 ` Felipe Contreras
2010-10-28 15:38                 ` Guzman Lugo, Fernando
2010-10-28 15:38                   ` Guzman Lugo, Fernando
2010-10-28 15:38                   ` Guzman Lugo, Fernando
2010-10-28 15:56                 ` Russell King - ARM Linux [this message]
2010-10-28 15:56                   ` Russell King - ARM Linux
2010-10-28 15:56                   ` Russell King - ARM Linux
2010-10-26  4:06 ` [PATCH 0/8] staging: tidspbridge - misc fixes Greg KH
2010-10-26  4:06   ` Greg KH
2010-10-26 14:43   ` Felipe Contreras
2010-10-26 14:43     ` Felipe Contreras
2010-10-26 14:55     ` Omar Ramirez Luna
2010-10-26 14:55       ` Omar Ramirez Luna
2010-10-26 14:55       ` Omar Ramirez Luna
2010-10-26 15:46     ` Guzman Lugo, Fernando
2010-10-26 15:46       ` Guzman Lugo, Fernando
2010-10-26 15:46       ` Guzman Lugo, Fernando

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=20101028155635.GF3122@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=andy.shevchenko@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=felipe.contreras@nokia.com \
    --cc=fernando.lugo@ti.com \
    --cc=gregkh@suse.de \
    --cc=hiroshi.doyu@nokia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@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.