On 12/10/18 9:39 AM, Carlos O'Donell wrote:
> On 12/10/18 11:27 AM, Jonathan Corbet wrote:
>> On Sat, 8 Dec 2018 20:38:56 -0800
>> Randy Dunlap wrote:
>>
>>> On 11/12/18 8:08 AM, Jonathan Corbet wrote:
On Sun, 11 Nov 2018 18:36:30 -0800
Greg KH wrote:
> We should have a
On 12/10/18 11:27 AM, Jonathan Corbet wrote:
> On Sat, 8 Dec 2018 20:38:56 -0800
> Randy Dunlap wrote:
>
>> On 11/12/18 8:08 AM, Jonathan Corbet wrote:
>>> On Sun, 11 Nov 2018 18:36:30 -0800
>>> Greg KH wrote:
>>>
We should have a checklist. That's a great idea. Now to find someone
On Sat, 8 Dec 2018 20:38:56 -0800
Randy Dunlap wrote:
> On 11/12/18 8:08 AM, Jonathan Corbet wrote:
> > On Sun, 11 Nov 2018 18:36:30 -0800
> > Greg KH wrote:
> >
> >> We should have a checklist. That's a great idea. Now to find someone
> >> to write it... :)
> >
> > Do we think the LPC
On 11/12/18 8:08 AM, Jonathan Corbet wrote:
> On Sun, 11 Nov 2018 18:36:30 -0800
> Greg KH wrote:
>
>> We should have a checklist. That's a great idea. Now to find someone
>> to write it... :)
>
> Do we think the LPC session might have the right people to create such a
> thing? If so, I can
From: David Newall
> Sent: 23 November 2018 14:11
>
> On 24/11/18 12:04 am, Florian Weimer wrote:
> > But socketcall does not exist on all architectures. Neither does
> > getpid, it's called getxpid on some architectures.
> > ...
> > I think it would be a poor approach to expose application
From: David Newall
> Sent: 23 November 2018 14:11
>
> On 24/11/18 12:04 am, Florian Weimer wrote:
> > But socketcall does not exist on all architectures. Neither does
> > getpid, it's called getxpid on some architectures.
> > ...
> > I think it would be a poor approach to expose application
On 24/11/18 1:53 am, Szabolcs Nagy wrote:
On 23/11/18 14:11, David Newall wrote:
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose
On 24/11/18 1:53 am, Szabolcs Nagy wrote:
On 23/11/18 14:11, David Newall wrote:
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose
On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote:
> On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
> > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> > >>
> > >>> If the kernel provides a system call, libc should provide a C wrapper
> > >>> for it, even if in
On Fri, Nov 23, 2018 at 12:15:39PM -0800, Daniel Colascione wrote:
> On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
> > > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> > >>
> > >>> If the kernel provides a system call, libc should provide a C wrapper
> > >>> for it, even if in
On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
>
> * Daniel Colascione:
>
> > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> >> * Daniel Colascione:
> >>
> >>> If the kernel provides a system call, libc should provide a C wrapper
> >>> for it, even if in the opinion of the libc
On Fri, Nov 23, 2018 at 5:34 AM Florian Weimer wrote:
>
> * Daniel Colascione:
>
> > On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
> >> * Daniel Colascione:
> >>
> >>> If the kernel provides a system call, libc should provide a C wrapper
> >>> for it, even if in the opinion of the libc
On 23/11/18 14:11, David Newall wrote:
> On 24/11/18 12:04 am, Florian Weimer wrote:
>> But socketcall does not exist on all architectures. Neither does
>> getpid, it's called getxpid on some architectures.
>> ...
>> I think it would be a poor approach to expose application developers to
>> these
On 23/11/18 14:11, David Newall wrote:
> On 24/11/18 12:04 am, Florian Weimer wrote:
>> But socketcall does not exist on all architectures. Neither does
>> getpid, it's called getxpid on some architectures.
>> ...
>> I think it would be a poor approach to expose application developers to
>> these
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose application developers to
these portability issues. We need to abstract over these
On 24/11/18 12:04 am, Florian Weimer wrote:
But socketcall does not exist on all architectures. Neither does
getpid, it's called getxpid on some architectures.
...
I think it would be a poor approach to expose application developers to
these portability issues. We need to abstract over these
* Daniel Colascione:
> On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
>> * Daniel Colascione:
>>
>>> If the kernel provides a system call, libc should provide a C wrapper
>>> for it, even if in the opinion of the libc maintainers, that system
>>> call is flawed.
>>
>> It's not that
* Daniel Colascione:
> On Mon, Nov 12, 2018 at 12:11 AM, Florian Weimer wrote:
>> * Daniel Colascione:
>>
>>> If the kernel provides a system call, libc should provide a C wrapper
>>> for it, even if in the opinion of the libc maintainers, that system
>>> call is flawed.
>>
>> It's not that
> I think the issue is a bit more complex :
> - linux doesn't support a single libc
> - glibc doesn't support a single OS
>
> In practice we all know (believe?) that both statements above are
> true but in practice 99% of the time there's a 1:1 relation between
> these two components.
The
> I think the issue is a bit more complex :
> - linux doesn't support a single libc
> - glibc doesn't support a single OS
>
> In practice we all know (believe?) that both statements above are
> true but in practice 99% of the time there's a 1:1 relation between
> these two components.
The
On 11/15/18 12:08 PM, Theodore Y. Ts'o wrote:
> On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote:
>> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
>>
>>> That's great. But is it or is it not true (either de jure or de
>>> facto) that "a single active glibc developer" can block a system
On 11/15/18 12:08 PM, Theodore Y. Ts'o wrote:
> On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote:
>> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
>>
>>> That's great. But is it or is it not true (either de jure or de
>>> facto) that "a single active glibc developer" can block a system
On 11/14/18 1:47 PM, Joseph Myers wrote:
> On Wed, 14 Nov 2018, Daniel Colascione wrote:
>
>> A good demonstration of a new commitment to pragmatism would be
>> merging the trivial wrappers for gettid(2).
>
> I support the addition of gettid (for use with those syscalls that take
> tids, and
On 11/14/18 1:47 PM, Joseph Myers wrote:
> On Wed, 14 Nov 2018, Daniel Colascione wrote:
>
>> A good demonstration of a new commitment to pragmatism would be
>> merging the trivial wrappers for gettid(2).
>
> I support the addition of gettid (for use with those syscalls that take
> tids, and
On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
> On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote:
> > On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
> >
> > > That's great. But is it or is it not true (either de jure or de
> > > facto) that "a single active glibc developer" can block a
On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
> On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote:
> > On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
> >
> > > That's great. But is it or is it not true (either de jure or de
> > > facto) that "a single active glibc developer" can block a
On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote:
> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
>
> > That's great. But is it or is it not true (either de jure or de
> > facto) that "a single active glibc developer" can block a system call
> > from being supported by glibc by
On Thu, Nov 15, 2018 at 04:29:43PM +, Joseph Myers wrote:
> On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
>
> > That's great. But is it or is it not true (either de jure or de
> > facto) that "a single active glibc developer" can block a system call
> > from being supported by glibc by
On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
> That's great. But is it or is it not true (either de jure or de
> facto) that "a single active glibc developer" can block a system call
> from being supported by glibc by objecting? And if not, under what is
> the process by resolving a conflict?
On Thu, 15 Nov 2018, Theodore Y. Ts'o wrote:
> That's great. But is it or is it not true (either de jure or de
> facto) that "a single active glibc developer" can block a system call
> from being supported by glibc by objecting? And if not, under what is
> the process by resolving a conflict?
On Wed, Nov 14, 2018 at 12:40:44PM +0100, Florian Weimer wrote:
> * Dave Martin:
>
> > Fair points, though this is rather what I meant by "sane essentials".
> > Because there are strict limits on what can be done in the vDSO, it may
> > be more bloat-resistant and more conservatively maintained.
On Wed, Nov 14, 2018 at 12:40:44PM +0100, Florian Weimer wrote:
> * Dave Martin:
>
> > Fair points, though this is rather what I meant by "sane essentials".
> > Because there are strict limits on what can be done in the vDSO, it may
> > be more bloat-resistant and more conservatively maintained.
On Wed, Nov 14, 2018 at 06:47:57PM +, Joseph Myers wrote:
> On Wed, 14 Nov 2018, Daniel Colascione wrote:
>
> > A good demonstration of a new commitment to pragmatism would be
> > merging the trivial wrappers for gettid(2).
>
> I support the addition of gettid (for use with those syscalls
On Wed, Nov 14, 2018 at 06:47:57PM +, Joseph Myers wrote:
> On Wed, 14 Nov 2018, Daniel Colascione wrote:
>
> > A good demonstration of a new commitment to pragmatism would be
> > merging the trivial wrappers for gettid(2).
>
> I support the addition of gettid (for use with those syscalls
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> A good demonstration of a new commitment to pragmatism would be
> merging the trivial wrappers for gettid(2).
I support the addition of gettid (for use with those syscalls that take
tids, and with appropriate documentation explaining the
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> A good demonstration of a new commitment to pragmatism would be
> merging the trivial wrappers for gettid(2).
I support the addition of gettid (for use with those syscalls that take
tids, and with appropriate documentation explaining the
On Wed, Nov 14, 2018 at 10:15 AM, Joseph Myers wrote:
> Any
> feature (e.g. syscall library) with a design coming solely from the kernel
> rather than a cooperative process is also likely to have an unsuitable
> design meaning it doesn't get used.
Is that so? membarrier came directly from the
On Wed, Nov 14, 2018 at 10:15 AM, Joseph Myers wrote:
> Any
> feature (e.g. syscall library) with a design coming solely from the kernel
> rather than a cooperative process is also likely to have an unsuitable
> design meaning it doesn't get used.
Is that so? membarrier came directly from the
On Wed, 14 Nov 2018, Arnd Bergmann wrote:
> Firoz Khan is in the process of doing part of this, by changing the
> in-kernel per-architecture unistd.h and syscall.S files into a
> architecture independent machine-readable format that is used to
> generate the existing files. The format will be
On Wed, 14 Nov 2018, Arnd Bergmann wrote:
> Firoz Khan is in the process of doing part of this, by changing the
> in-kernel per-architecture unistd.h and syscall.S files into a
> architecture independent machine-readable format that is used to
> generate the existing files. The format will be
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> > there is a lot of bikesheding here by people who
> > don't understand the constraints nor the use-cases.
>
> Conversely, there's a lot of doubt-sowing from the other side that
"other side" is the wrong concept here in the first place - it's
On Wed, 14 Nov 2018, Daniel Colascione wrote:
> > there is a lot of bikesheding here by people who
> > don't understand the constraints nor the use-cases.
>
> Conversely, there's a lot of doubt-sowing from the other side that
"other side" is the wrong concept here in the first place - it's
On 11/14/18 9:40 AM, Joseph Myers wrote:
Historically, there was once an attempt to rework POSIX into a separate
language-independent definition and language bindings (for C, Fortran, Ada
etc.), but I don't think it got anywhere, and it's probably doubtful
whether the idea was ever very
On 11/14/18 9:40 AM, Joseph Myers wrote:
Historically, there was once an attempt to rework POSIX into a separate
language-independent definition and language bindings (for C, Fortran, Ada
etc.), but I don't think it got anywhere, and it's probably doubtful
whether the idea was ever very
On Wed, 14 Nov 2018, Andy Lutomirski wrote:
> I’m not so sure it’s useless. Historically, POSIX systems have, in
> practice and almost by definition, been very C focused, but the world is
> changing. A less crufty library could be useful for newer languages:
Historically, there was once an
On Wed, 14 Nov 2018, Andy Lutomirski wrote:
> I’m not so sure it’s useless. Historically, POSIX systems have, in
> practice and almost by definition, been very C focused, but the world is
> changing. A less crufty library could be useful for newer languages:
Historically, there was once an
On Wed, Nov 14, 2018 at 6:58 AM Carlos O'Donell wrote:
> On 11/14/18 6:58 AM, Szabolcs Nagy wrote:
> > an actual proposal in the thread that i think is
> > worth considering is to make the linux syscall
> > design process involve libc devs so the c api is
> > designed together with the syscall
On Wed, Nov 14, 2018 at 6:58 AM Carlos O'Donell wrote:
> On 11/14/18 6:58 AM, Szabolcs Nagy wrote:
> > an actual proposal in the thread that i think is
> > worth considering is to make the linux syscall
> > design process involve libc devs so the c api is
> > designed together with the syscall
On Wed, Nov 14, 2018 at 3:58 AM, Szabolcs Nagy wrote:
> On 13/11/18 19:39, Dave Martin wrote:
>> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>>> We should adopt a similar approach. Shipping a lower-level
>>> "liblinux.so" tightly bound to the kernel would not only let the
On Wed, Nov 14, 2018 at 3:58 AM, Szabolcs Nagy wrote:
> On 13/11/18 19:39, Dave Martin wrote:
>> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>>> We should adopt a similar approach. Shipping a lower-level
>>> "liblinux.so" tightly bound to the kernel would not only let the
* Andy Lutomirski:
> Thread cancellation is a big mess, and we only really need to support
> it because on legacy code. The whole mechanism should IMO be
> considered extremely deprecated.
The part regarding legacy code is not true: people write new code using
it all the time. It's true that
* Andy Lutomirski:
> Thread cancellation is a big mess, and we only really need to support
> it because on legacy code. The whole mechanism should IMO be
> considered extremely deprecated.
The part regarding legacy code is not true: people write new code using
it all the time. It's true that
On 11/14/18 6:58 AM, Szabolcs Nagy wrote:
> an actual proposal in the thread that i think is
> worth considering is to make the linux syscall
> design process involve libc devs so the c api is
> designed together with the syscall abi.
Right, I see at least 2 actionable items:
* "The Checklist"
On 11/14/18 6:58 AM, Szabolcs Nagy wrote:
> an actual proposal in the thread that i think is
> worth considering is to make the linux syscall
> design process involve libc devs so the c api is
> designed together with the syscall abi.
Right, I see at least 2 actionable items:
* "The Checklist"
> On Nov 14, 2018, at 3:58 AM, Szabolcs Nagy wrote:
>
>> On 13/11/18 19:39, Dave Martin wrote:
>>> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>>> We should adopt a similar approach. Shipping a lower-level
>>> "liblinux.so" tightly bound to the kernel would not only
> On Nov 14, 2018, at 3:58 AM, Szabolcs Nagy wrote:
>
>> On 13/11/18 19:39, Dave Martin wrote:
>>> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>>> We should adopt a similar approach. Shipping a lower-level
>>> "liblinux.so" tightly bound to the kernel would not only
* Adam Borowski:
> On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
>> A lot of multi-threaded applications assume that most high-level
>> functionality remains usable even after fork in a multi-threaded
>> process.
>
> How would this be even possible? Currently fork kills all
* Adam Borowski:
> On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
>> A lot of multi-threaded applications assume that most high-level
>> functionality remains usable even after fork in a multi-threaded
>> process.
>
> How would this be even possible? Currently fork kills all
On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
> A lot of multi-threaded applications assume that most high-level
> functionality remains usable even after fork in a multi-threaded
> process.
How would this be even possible? Currently fork kills all threads
(save for the
On Sun, Nov 11, 2018 at 12:46:35PM +0100, Florian Weimer wrote:
> A lot of multi-threaded applications assume that most high-level
> functionality remains usable even after fork in a multi-threaded
> process.
How would this be even possible? Currently fork kills all threads
(save for the
On 13/11/18 19:39, Dave Martin wrote:
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>> We should adopt a similar approach. Shipping a lower-level
>> "liblinux.so" tightly bound to the kernel would not only let the
>> kernel bypass glibc's "editorial discretion" in exposing
On 13/11/18 19:39, Dave Martin wrote:
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>> We should adopt a similar approach. Shipping a lower-level
>> "liblinux.so" tightly bound to the kernel would not only let the
>> kernel bypass glibc's "editorial discretion" in exposing
* Dave Martin:
> Fair points, though this is rather what I meant by "sane essentials".
> Because there are strict limits on what can be done in the vDSO, it may
> be more bloat-resistant and more conservatively maintained.
>
> This might provide a way to push some dumb compatibility kludge code
>
* Dave Martin:
> Fair points, though this is rather what I meant by "sane essentials".
> Because there are strict limits on what can be done in the vDSO, it may
> be more bloat-resistant and more conservatively maintained.
>
> This might provide a way to push some dumb compatibility kludge code
>
On Tue, Nov 13, 2018 at 12:58:39PM -0800, Andy Lutomirski wrote:
>
> > On Nov 13, 2018, at 11:39 AM, Dave Martin wrote:
> >
> > On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
> >
> > [...]
> >
> >> We can learn something from how Windows does things. On that system,
> >>
On Tue, Nov 13, 2018 at 12:58:39PM -0800, Andy Lutomirski wrote:
>
> > On Nov 13, 2018, at 11:39 AM, Dave Martin wrote:
> >
> > On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
> >
> > [...]
> >
> >> We can learn something from how Windows does things. On that system,
> >>
> On Nov 13, 2018, at 11:39 AM, Dave Martin wrote:
>
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>
> [...]
>
>> We can learn something from how Windows does things. On that system,
>> what we think of as "libc" is actually two parts. (More, actually, but
>> I'm
> On Nov 13, 2018, at 11:39 AM, Dave Martin wrote:
>
> On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
>
> [...]
>
>> We can learn something from how Windows does things. On that system,
>> what we think of as "libc" is actually two parts. (More, actually, but
>> I'm
On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
[...]
> We can learn something from how Windows does things. On that system,
> what we think of as "libc" is actually two parts. (More, actually, but
> I'm simplifying.) At the lowest level, you have the semi-documented
>
On Mon, Nov 12, 2018 at 05:19:14AM -0800, Daniel Colascione wrote:
[...]
> We can learn something from how Windows does things. On that system,
> what we think of as "libc" is actually two parts. (More, actually, but
> I'm simplifying.) At the lowest level, you have the semi-documented
>
On 11/12/18 11:43 AM, Joseph Myers wrote:
> On Sun, 11 Nov 2018, Florian Weimer wrote:
>
>> People may have disappeared from glibc development who have objected to
>> gettid. I thought this was the case with strlcpy/strlcat, but it was
>> not.
>
> Well, I know of two main people who were
On 11/12/18 11:43 AM, Joseph Myers wrote:
> On Sun, 11 Nov 2018, Florian Weimer wrote:
>
>> People may have disappeared from glibc development who have objected to
>> gettid. I thought this was the case with strlcpy/strlcat, but it was
>> not.
>
> Well, I know of two main people who were
On Mon, 12 Nov 2018, Daniel Colascione wrote:
> I initially wanted to put the APIs in libc. I still do. But that's
> proving to be impractical, for the reasons we're discussing on this
> thread.
Well, your proposed APIs didn't attract consensus among libc developers.
> > (I can imagine *other*
On Mon, 12 Nov 2018, Daniel Colascione wrote:
> I initially wanted to put the APIs in libc. I still do. But that's
> proving to be impractical, for the reasons we're discussing on this
> thread.
Well, your proposed APIs didn't attract consensus among libc developers.
> > (I can imagine *other*
On Mon, Nov 12, 2018 at 2:51 PM, Joseph Myers wrote:
> I see no obvious reason why a kernel-provided
> library, with all the problems that entails, should need to be involved,
> rather than putting new APIs either in libc
I initially wanted to put the APIs in libc. I still do. But that's
proving
On Mon, Nov 12, 2018 at 2:51 PM, Joseph Myers wrote:
> I see no obvious reason why a kernel-provided
> library, with all the problems that entails, should need to be involved,
> rather than putting new APIs either in libc
I initially wanted to put the APIs in libc. I still do. But that's
proving
On Mon, 12 Nov 2018, Daniel Colascione wrote:
> The two features *are* unrelated. The design I've proposed works
> equally well for synchronous and asynchronous signals, and limiting it
Whatever the design, I see no obvious reason why a kernel-provided
library, with all the problems that
On Mon, 12 Nov 2018, Daniel Colascione wrote:
> The two features *are* unrelated. The design I've proposed works
> equally well for synchronous and asynchronous signals, and limiting it
Whatever the design, I see no obvious reason why a kernel-provided
library, with all the problems that
On Mon, 12 Nov 2018, Florian Weimer wrote:
> For that use case, a machine-readable system call ABI specification is
> the only reasonable approach: Some people want inline system calls,
I also think it's much more likely to be of use to glibc than any syscall
library provided by the kernel. I
On Mon, 12 Nov 2018, Florian Weimer wrote:
> For that use case, a machine-readable system call ABI specification is
> the only reasonable approach: Some people want inline system calls,
I also think it's much more likely to be of use to glibc than any syscall
library provided by the kernel. I
On Mon, Nov 12, 2018 at 09:08:28AM -0700, Jonathan Corbet wrote:
> On Sun, 11 Nov 2018 18:36:30 -0800
> Greg KH wrote:
>
> > We should have a checklist. That's a great idea. Now to find someone
> > to write it... :)
>
> Do we think the LPC session might have the right people to create such a
On Mon, Nov 12, 2018 at 09:08:28AM -0700, Jonathan Corbet wrote:
> On Sun, 11 Nov 2018 18:36:30 -0800
> Greg KH wrote:
>
> > We should have a checklist. That's a great idea. Now to find someone
> > to write it... :)
>
> Do we think the LPC session might have the right people to create such a
On Mon, Nov 12, 2018 at 11:11 AM, Florian Weimer wrote:
> * Daniel Colascione:
>
>> What about off_t differences? Again, it doesn't matter. From the
>> *kernel's* point of view, there's one width of offset parameter per
>> system call per architecture. The library I'm proposing would expose
>>
On Mon, Nov 12, 2018 at 11:11 AM, Florian Weimer wrote:
> * Daniel Colascione:
>
>> What about off_t differences? Again, it doesn't matter. From the
>> *kernel's* point of view, there's one width of offset parameter per
>> system call per architecture. The library I'm proposing would expose
>>
* Daniel Colascione:
> What about off_t differences? Again, it doesn't matter. From the
> *kernel's* point of view, there's one width of offset parameter per
> system call per architecture. The library I'm proposing would expose
> this parameter literally.
Does this mean the application author
* Daniel Colascione:
> What about off_t differences? Again, it doesn't matter. From the
> *kernel's* point of view, there's one width of offset parameter per
> system call per architecture. The library I'm proposing would expose
> this parameter literally.
Does this mean the application author
On Mon, Nov 12, 2018 at 9:24 AM, Zack Weinberg wrote:
> Daniel Colascione wrote:
>> >> If the kernel provides a system call, libc should provide a C wrapper
>> >> for it, even if in the opinion of the libc maintainers, that system
>> >> call is flawed.
>
> I would like to state general support
On Mon, Nov 12, 2018 at 9:24 AM, Zack Weinberg wrote:
> Daniel Colascione wrote:
>> >> If the kernel provides a system call, libc should provide a C wrapper
>> >> for it, even if in the opinion of the libc maintainers, that system
>> >> call is flawed.
>
> I would like to state general support
On 11/12/18 10:09 AM, Joseph Myers wrote:
> On Mon, 12 Nov 2018, Greg KH wrote:
>
>> If there are still problems with this, please let us know and we will be
>> glad to resolve them.
>
> With headers installed from Linus's latest tree, I retried (for x86_64)
> the case of a source file
On 11/12/18 10:09 AM, Joseph Myers wrote:
> On Mon, 12 Nov 2018, Greg KH wrote:
>
>> If there are still problems with this, please let us know and we will be
>> glad to resolve them.
>
> With headers installed from Linus's latest tree, I retried (for x86_64)
> the case of a source file
On Mon, 12 Nov 2018, Greg KH wrote:
> If there are still problems with this, please let us know and we will be
> glad to resolve them.
With headers installed from Linus's latest tree, I retried (for x86_64)
the case of a source file containing the single line
#include
which (as previously
On Mon, 12 Nov 2018, Greg KH wrote:
> If there are still problems with this, please let us know and we will be
> glad to resolve them.
With headers installed from Linus's latest tree, I retried (for x86_64)
the case of a source file containing the single line
#include
which (as previously
On Mon, Nov 12, 2018 at 05:36:11PM +, Joseph Myers wrote:
> What *is*, in my view, a bug in the uapi headers is that some of them
> don't work when included on their own. I'd expect #include
> or #include , for any such header
> installed by make headers_install, to compile on its own in
On Mon, Nov 12, 2018 at 05:36:11PM +, Joseph Myers wrote:
> What *is*, in my view, a bug in the uapi headers is that some of them
> don't work when included on their own. I'd expect #include
> or #include , for any such header
> installed by make headers_install, to compile on its own in
Daniel Colascione wrote:
> >> If the kernel provides a system call, libc should provide a C wrapper
> >> for it, even if in the opinion of the libc maintainers, that system
> >> call is flawed.
I would like to state general support for this principle; in fact, I
seriously considered preparing
Daniel Colascione wrote:
> >> If the kernel provides a system call, libc should provide a C wrapper
> >> for it, even if in the opinion of the libc maintainers, that system
> >> call is flawed.
I would like to state general support for this principle; in fact, I
seriously considered preparing
On Sun, 11 Nov 2018, Willy Tarreau wrote:
> > The kernel developers care not, and the result is that we
> > copy definitions and declarations from the kernel header files, creating
> > additional problems.
>
> Probably that these standard compatibility issues should be addressed at
> their root
On Sun, 11 Nov 2018, Willy Tarreau wrote:
> > The kernel developers care not, and the result is that we
> > copy definitions and declarations from the kernel header files, creating
> > additional problems.
>
> Probably that these standard compatibility issues should be addressed at
> their root
On Sun, 11 Nov 2018, Florian Weimer wrote:
> The kernel does not know about TCB layout, so a lot of low-level
> threading aspects are defined by userspace.
>
> The kernel does not know about POSIX cancellation. Directly calling
> system calls breaks support for that.
Indeed. Where
On Sun, 11 Nov 2018, Florian Weimer wrote:
> The kernel does not know about TCB layout, so a lot of low-level
> threading aspects are defined by userspace.
>
> The kernel does not know about POSIX cancellation. Directly calling
> system calls breaks support for that.
Indeed. Where
1 - 100 of 164 matches
Mail list logo
