Desnoyers ,"linux-...@vger.kernel.org"
,"linux-kernel@vger.kernel.org"
,Peter Zijlstra
Message-ID:
Let me see if I can unbury it - probably not until Monday, though.
On July 31, 2015 11:18:06 PM PDT, Josh Triplett wrote:
>On Fri, Jul 31, 2015 at 09:56:46PM -0700, H. Peter Anvin wrote:
>> On
On Fri, Jul 31, 2015 at 09:56:46PM -0700, H. Peter Anvin wrote:
> On 07/31/2015 09:32 PM, Josh Triplett wrote:
> >
> > Sure, agreed. But I really hope we don't create new kernel ABIs that
> > involve constructs like that.
> >
>
> It's worth noting I have pushed for auto-marshalling in general
Desnoyers mathieu.desnoy...@efficios.com,linux-...@vger.kernel.org
linux-...@vger.kernel.org,linux-kernel@vger.kernel.org
linux-kernel@vger.kernel.org,Peter Zijlstra a.p.zijls...@chello.nl
Message-ID: d190a265-cbf0-460e-b12a-df0e802c5...@zytor.com
Let me see if I can unbury it - probably not
On Fri, Jul 31, 2015 at 09:56:46PM -0700, H. Peter Anvin wrote:
On 07/31/2015 09:32 PM, Josh Triplett wrote:
Sure, agreed. But I really hope we don't create new kernel ABIs that
involve constructs like that.
It's worth noting I have pushed for auto-marshalling in general for a
long
On 07/31/2015 09:32 PM, Josh Triplett wrote:
>
> Sure, agreed. But I really hope we don't create new kernel ABIs that
> involve constructs like that.
>
It's worth noting I have pushed for auto-marshalling in general for a
long time, not the least to get rid of the awful syscall(3) wrapper. I
On Fri, Jul 31, 2015 at 03:54:56PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 31, 2015 at 3:08 PM, wrote:
> > On Fri, Jul 31, 2015 at 02:19:29PM -0700, Andy Lutomirski wrote:
> >> On Fri, Jul 31, 2015 at 1:59 PM, wrote:
> >> > Agreed. I think the proposal above would be a net improvement,
On Fri, Jul 31, 2015 at 3:08 PM, wrote:
> On Fri, Jul 31, 2015 at 02:19:29PM -0700, Andy Lutomirski wrote:
>> On Fri, Jul 31, 2015 at 1:59 PM, wrote:
>> > Agreed. I think the proposal above would be a net improvement, but
>> > ideally you'd want something that's annotated and generates
On Fri, Jul 31, 2015 at 02:19:29PM -0700, Andy Lutomirski wrote:
> On Fri, Jul 31, 2015 at 1:59 PM, wrote:
> > Agreed. I think the proposal above would be a net improvement, but
> > ideally you'd want something that's annotated and generates automatic
> > marshalling code.
> >
>
> I assume
On Fri, Jul 31, 2015 at 1:59 PM, wrote:
> On Fri, Jul 31, 2015 at 11:56:06AM -0700, Kees Cook wrote:
>> On Thu, Jul 30, 2015 at 6:02 PM, Josh Triplett wrote:
>> > On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
>> >> On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett
>> >> wrote:
>>
On Fri, Jul 31, 2015 at 11:56:06AM -0700, Kees Cook wrote:
> On Thu, Jul 30, 2015 at 6:02 PM, Josh Triplett wrote:
> > On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
> >> On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett
> >> wrote:
> >> > On Thu, Jul 30, 2015 at 11:21:54AM -0700,
On Thu, Jul 30, 2015 at 6:02 PM, Josh Triplett wrote:
> On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
>> On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett
>> wrote:
>> > On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
>> >> I like this, it's a good description of both
On Fri, Jul 31, 2015 at 2:06 PM, Josh Triplett wrote:
> On Fri, Jul 31, 2015 at 10:48:32AM +0100, David Drysdale wrote:
>> On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett wrote:
>> > On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
>> >> +needs to be governed by the appropriate
On Fri, Jul 31, 2015 at 10:48:32AM +0100, David Drysdale wrote:
> On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett wrote:
> > On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
> >> Add a document describing the process of adding a new system call,
> >> including the need for a flags
On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett wrote:
> On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
>> Add a document describing the process of adding a new system call,
>> including the need for a flags argument for future compatibility, and
>> covering 32-bit/64-bit concerns
On Fri, Jul 31, 2015 at 03:54:56PM -0700, Andy Lutomirski wrote:
On Fri, Jul 31, 2015 at 3:08 PM, j...@joshtriplett.org wrote:
On Fri, Jul 31, 2015 at 02:19:29PM -0700, Andy Lutomirski wrote:
On Fri, Jul 31, 2015 at 1:59 PM, j...@joshtriplett.org wrote:
Agreed. I think the proposal
On 07/31/2015 09:32 PM, Josh Triplett wrote:
Sure, agreed. But I really hope we don't create new kernel ABIs that
involve constructs like that.
It's worth noting I have pushed for auto-marshalling in general for a
long time, not the least to get rid of the awful syscall(3) wrapper. I
even
On Fri, Jul 31, 2015 at 10:48:32AM +0100, David Drysdale wrote:
On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
Add a document describing the process of adding a new system call,
including the need
On Fri, Jul 31, 2015 at 2:06 PM, Josh Triplett j...@joshtriplett.org wrote:
On Fri, Jul 31, 2015 at 10:48:32AM +0100, David Drysdale wrote:
On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
+needs to be
On Thu, Jul 30, 2015 at 6:02 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett j...@joshtriplett.org
wrote:
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
I like this, it's a
On Fri, Jul 31, 2015 at 02:19:29PM -0700, Andy Lutomirski wrote:
On Fri, Jul 31, 2015 at 1:59 PM, j...@joshtriplett.org wrote:
Agreed. I think the proposal above would be a net improvement, but
ideally you'd want something that's annotated and generates automatic
marshalling code.
I
On Fri, Jul 31, 2015 at 11:56:06AM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 6:02 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett j...@joshtriplett.org
wrote:
On Thu, Jul 30,
On Fri, Jul 31, 2015 at 1:59 PM, j...@joshtriplett.org wrote:
On Fri, Jul 31, 2015 at 11:56:06AM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 6:02 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 12:04 PM,
On Fri, Jul 31, 2015 at 3:08 PM, j...@joshtriplett.org wrote:
On Fri, Jul 31, 2015 at 02:19:29PM -0700, Andy Lutomirski wrote:
On Fri, Jul 31, 2015 at 1:59 PM, j...@joshtriplett.org wrote:
Agreed. I think the proposal above would be a net improvement, but
ideally you'd want something
On Thu, Jul 30, 2015 at 7:50 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
Add a document describing the process of adding a new system call,
including the need for a flags argument for future compatibility, and
covering
On Thu, Jul 30, 2015 at 06:02:34PM -0700, Josh Triplett wrote:
> On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
> > On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett
> > wrote:
> > > On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
> > >> I like this, it's a good description
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
> On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett wrote:
> > On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
> >> I like this, it's a good description of both options. I'm still biased
> >> about the approach: I prefer flags,
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett wrote:
> On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
>> I like this, it's a good description of both options. I'm still biased
>> about the approach: I prefer flags, since pointers to user structures
>> complicate syscall filtering.
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
> I like this, it's a good description of both options. I'm still biased
> about the approach: I prefer flags, since pointers to user structures
> complicate syscall filtering. ;)
Seems like we should do two things to make that easier:
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
> Add a document describing the process of adding a new system call,
> including the need for a flags argument for future compatibility, and
> covering 32-bit/64-bit concerns (albeit in an x86-centric way).
>
> Signed-off-by: David
On Thu, Jul 30, 2015 at 10:38:31AM +0200, Ingo Molnar wrote:
> When the system call is extended in the future on the kernel side, with 'u64
> param_4', then the structure expands from an old size of 24 to a new size of
> 32
> bytes. The following scenarios might occur:
>
> - the common case:
On Thu, Jul 30, 2015 at 4:10 AM, David Drysdale wrote:
> On Thu, Jul 30, 2015 at 9:38 AM, Ingo Molnar wrote:
>>
>> * David Drysdale wrote:
>>
>>> +Designing the API
>>> +-
>>> +
>>> +A new system call forms part of the API of the kernel, and has to be
>>> supported
>>>
On Thu, Jul 30, 2015 at 06:30:07PM +0200, Cyril Hrubis wrote:
> Hi!
> > +Testing
> > +---
> > +
> > +A new system call should obviously be tested; it is also useful to provide
> > +reviewers with a demonstration of how user space programs will use the
> > system
> > +call. A good way to
Hi!
> +Testing
> +---
> +
> +A new system call should obviously be tested; it is also useful to provide
> +reviewers with a demonstration of how user space programs will use the system
> +call. A good way to combine these aims is to include a simple self-test
> +program in a new directory
On Thu, Jul 30, 2015 at 9:38 AM, Ingo Molnar wrote:
>
> * David Drysdale wrote:
>
>> +Designing the API
>> +-
>> +
>> +A new system call forms part of the API of the kernel, and has to be
>> supported
>> +indefinitely. As such, it's a very good idea to explicitly discuss the
>>
* David Drysdale wrote:
> +Designing the API
> +-
> +
> +A new system call forms part of the API of the kernel, and has to be
> supported
> +indefinitely. As such, it's a very good idea to explicitly discuss the
> +interface on the kernel mailing list, and to plan for future
Add a document describing the process of adding a new system call,
including the need for a flags argument for future compatibility, and
covering 32-bit/64-bit concerns (albeit in an x86-centric way).
Signed-off-by: David Drysdale
Reviewed-by: Michael Kerrisk
Reviewed-by: Eric B Munson
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
I like this, it's a good description of both options. I'm still biased
about the approach: I prefer flags, since pointers to user structures
complicate
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett j...@joshtriplett.org wrote:
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
I like this, it's a good description of both options. I'm still biased
about the approach: I
On Thu, Jul 30, 2015 at 06:02:34PM -0700, Josh Triplett wrote:
On Thu, Jul 30, 2015 at 01:03:43PM -0700, Kees Cook wrote:
On Thu, Jul 30, 2015 at 12:04 PM, Josh Triplett j...@joshtriplett.org
wrote:
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
I like this, it's a good
On Thu, Jul 30, 2015 at 11:21:54AM -0700, Kees Cook wrote:
I like this, it's a good description of both options. I'm still biased
about the approach: I prefer flags, since pointers to user structures
complicate syscall filtering. ;)
Seems like we should do two things to make that easier:
1)
Add a document describing the process of adding a new system call,
including the need for a flags argument for future compatibility, and
covering 32-bit/64-bit concerns (albeit in an x86-centric way).
Signed-off-by: David Drysdale drysd...@google.com
Reviewed-by: Michael Kerrisk
* David Drysdale drysd...@google.com wrote:
+Designing the API
+-
+
+A new system call forms part of the API of the kernel, and has to be
supported
+indefinitely. As such, it's a very good idea to explicitly discuss the
+interface on the kernel mailing list, and to plan
On Thu, Jul 30, 2015 at 4:10 AM, David Drysdale drysd...@google.com wrote:
On Thu, Jul 30, 2015 at 9:38 AM, Ingo Molnar mi...@kernel.org wrote:
* David Drysdale drysd...@google.com wrote:
+Designing the API
+-
+
+A new system call forms part of the API of the kernel, and
On Thu, Jul 30, 2015 at 10:38:31AM +0200, Ingo Molnar wrote:
When the system call is extended in the future on the kernel side, with 'u64
param_4', then the structure expands from an old size of 24 to a new size of
32
bytes. The following scenarios might occur:
- the common case: new
On Thu, Jul 30, 2015 at 06:30:07PM +0200, Cyril Hrubis wrote:
Hi!
+Testing
+---
+
+A new system call should obviously be tested; it is also useful to provide
+reviewers with a demonstration of how user space programs will use the
system
+call. A good way to combine these aims
Hi!
+Testing
+---
+
+A new system call should obviously be tested; it is also useful to provide
+reviewers with a demonstration of how user space programs will use the system
+call. A good way to combine these aims is to include a simple self-test
+program in a new directory under
On Thu, Jul 30, 2015 at 08:52:11AM +0100, David Drysdale wrote:
Add a document describing the process of adding a new system call,
including the need for a flags argument for future compatibility, and
covering 32-bit/64-bit concerns (albeit in an x86-centric way).
Signed-off-by: David
On Thu, Jul 30, 2015 at 9:38 AM, Ingo Molnar mi...@kernel.org wrote:
* David Drysdale drysd...@google.com wrote:
+Designing the API
+-
+
+A new system call forms part of the API of the kernel, and has to be
supported
+indefinitely. As such, it's a very good idea to
48 matches
Mail list logo
