linux-kernel - Re: [PATCH 1/8] staging: tidspbridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101028155635.GF3122@n2100.arm.linux.org.uk>
Date:	Thu, 28 Oct 2010 16:56:35 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Felipe Contreras <felipe.contreras@...il.com>
Cc:	"Guzman Lugo, Fernando" <fernando.lugo@...com>,
	"gregkh@...e.de" <gregkh@...e.de>,
	"hiroshi.doyu@...ia.com" <hiroshi.doyu@...ia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Felipe Contreras <felipe.contreras@...ia.com>,
	"andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/8] staging: tidspbridge - remove req_addr from
	proc_map

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/