On Wed, Feb 17, 2016 at 09:22:10AM +0100, Heiko Carstens wrote:
> On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > > However I'll try to write an addon patch to your patch series. Maybe we
> > > can
> > > still get rid of compat_wrapper.c in a way which makes both of us happy.
> >
On Wed, Feb 17, 2016 at 09:22:10AM +0100, Heiko Carstens wrote:
> On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > > However I'll try to write an addon patch to your patch series. Maybe we
> > > can
> > > still get rid of compat_wrapper.c in a way which makes both of us happy.
> >
On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > However I'll try to write an addon patch to your patch series. Maybe we can
> > still get rid of compat_wrapper.c in a way which makes both of us happy.
> > Also.. the idea with the alias names for compat wrappers does seem to have
>
On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> > However I'll try to write an addon patch to your patch series. Maybe we can
> > still get rid of compat_wrapper.c in a way which makes both of us happy.
> > Also.. the idea with the alias names for compat wrappers does seem to have
>
On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> > So I think I can summarize my point to: if you can enforce correctness, why
> > shouldn't you do it if the performance impact is only a single instruction.
>
> For
On Tue, Feb 02, 2016 at 11:41:56PM +0300, Yury Norov wrote:
> On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> > So I think I can summarize my point to: if you can enforce correctness, why
> > shouldn't you do it if the performance impact is only a single instruction.
>
> For
On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> Hi Yury,
>
> On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> > See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> > "unsigned int" instead of u_long") would have been a candidate which
Hi Yury,
On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> "unsigned int" instead of u_long") would have been a candidate which could
> silently break architectures which need compat wrappers.
Ok, this
On Tue, Feb 02, 2016 at 06:43:31PM +0300, Yury Norov wrote:
> > Well, I'd like to have some proof by the compiler or linker that nothing
> > went wrong. Which seems hard if only selected system call defines will be
> > converted to the new defines.
> >
> > How can you tell that nothing has been
On Tue, Feb 02, 2016 at 08:39:13AM +0100, Heiko Carstens wrote:
> On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> > Hi Heiko,
> >
> > I tried this idea, and I don't like what happened.
> > - Wrappers around safe syscalls does exist. We can remove it by
> >overcomplicating
On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> Hi Yury,
>
> On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> > See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> > "unsigned int" instead of u_long") would have been a candidate which
Hi Yury,
On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> "unsigned int" instead of u_long") would have been a candidate which could
> silently break architectures which need compat wrappers.
Ok, this
On Tue, Feb 02, 2016 at 08:39:13AM +0100, Heiko Carstens wrote:
> On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> > Hi Heiko,
> >
> > I tried this idea, and I don't like what happened.
> > - Wrappers around safe syscalls does exist. We can remove it by
> >overcomplicating
On Tue, Feb 02, 2016 at 06:43:31PM +0300, Yury Norov wrote:
> > Well, I'd like to have some proof by the compiler or linker that nothing
> > went wrong. Which seems hard if only selected system call defines will be
> > converted to the new defines.
> >
> > How can you tell that nothing has been
On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> Hi Heiko,
>
> I tried this idea, and I don't like what happened.
> - Wrappers around safe syscalls does exist. We can remove it by
>overcomplicating __SC_COMPAT_CAST, but I don't like it.
> - We still need to declare numerous
On Thu, Jan 28, 2016 at 07:31:09PM +0300, Yury Norov wrote:
> On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote:
> > Hello Yury,
> >
> > On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> > > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length,
> > > so
On Thu, Jan 28, 2016 at 07:31:09PM +0300, Yury Norov wrote:
> On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote:
> > Hello Yury,
> >
> > On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> > > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length,
> > > so
On Mon, Feb 01, 2016 at 02:42:51PM +0300, Yury Norov wrote:
> Hi Heiko,
>
> I tried this idea, and I don't like what happened.
> - Wrappers around safe syscalls does exist. We can remove it by
>overcomplicating __SC_COMPAT_CAST, but I don't like it.
> - We still need to declare numerous
On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote:
> Hello Yury,
>
> On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so
> > it's
> > moved to arch/s390/include/asm/compat.h. Generic declaration
Hello Yury,
On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so
> it's
> moved to arch/s390/include/asm/compat.h. Generic declaration assumes that
> long,
> unsigned long and pointer types are all 32-bit
On Thu, Jan 28, 2016 at 01:16:18PM +0100, Heiko Carstens wrote:
> Hello Yury,
>
> On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> > __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so
> > it's
> > moved to arch/s390/include/asm/compat.h. Generic declaration
Hello Yury,
On Mon, Jan 25, 2016 at 07:57:23PM +0300, Yury Norov wrote:
> __SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so
> it's
> moved to arch/s390/include/asm/compat.h. Generic declaration assumes that
> long,
> unsigned long and pointer types are all 32-bit
Hi Yury,
[auto build test ERROR on v4.4-rc8]
[also build test ERROR on next-20160125]
[cannot apply to s390/features v4.5-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
__SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long,
unsigned long and pointer types are all 32-bit length.
linux/syscalls_structs.h header is introduced, because from now (see next patch)
__SC_COMPAT_CAST for s390 is too specific due to 31-bit pointer length, so it's
moved to arch/s390/include/asm/compat.h. Generic declaration assumes that long,
unsigned long and pointer types are all 32-bit length.
linux/syscalls_structs.h header is introduced, because from now (see next patch)
Hi Yury,
[auto build test ERROR on v4.4-rc8]
[also build test ERROR on next-20160125]
[cannot apply to s390/features v4.5-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
26 matches
Mail list logo
