On Sun, Apr 17, 2016 at 08:00:54PM -0700, H. Peter Anvin wrote:
> Now, we could of course have __linux_getrandom() and make a weak alias
> for getrandom(), but I really don't understand the use case for
> exporting all the system calls.
If we do create a libinux library, I'd definitely want getran
On April 18, 2016 2:14:12 AM PDT, "Richard W.M. Jones"
wrote:
>On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote:
>> O_NOUMASK seems potentially useful to support implementation of umask
>> entirely in userspace, which also addresses thread-safety. A program
>> could read its process
On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote:
> O_NOUMASK seems potentially useful to support implementation of umask
> entirely in userspace, which also addresses thread-safety. A program
> could read its process umask out at startup, handle umask entirely in
> userspace (includi
On 04/17/16 19:37, Josh Triplett wrote:
>
> It seems like one of the main problems with syscall() is that it forces
> userspace to handle weird ABI issues, such as syscall numbers varying by
> architecture, encoding of 64-bit arguments on 32-bit platforms (see the
> example in the syscall manpage)
On Sun, Apr 17, 2016 at 07:15:31PM -0700, H. Peter Anvin wrote:
> On 04/17/16 19:12, Josh Triplett wrote:
> >>
> >> I really like the 'libinux' idea, did anyone every hack up a first-pass
> >> at this? And I'm guessing we have more syscalls now that would need to
> >> be added (like getrandom(), b
On 04/17/16 19:12, Josh Triplett wrote:
>>
>> I really like the 'libinux' idea, did anyone every hack up a first-pass
>> at this? And I'm guessing we have more syscalls now that would need to
>> be added (like getrandom(), but that shouldn't be too difficult.
>
> Personally, I'd suggest that libi
On Mon, Apr 18, 2016 at 10:09:25AM +0900, Greg KH wrote:
> On Sun, Apr 17, 2016 at 05:38:24PM -0700, H. Peter Anvin wrote:
> > On 04/13/16 19:13, Theodore Ts'o wrote:
> > >
> > > One other reason to suggest using a /proc file is that you're not at
> > > the mercy of the glibc folks to wire up a ne
On 04/17/16 18:09, Greg KH wrote:
>>
>> There aren't a *lot* of such system calls, but even in that thread the
>> "oh, only two applications need this, let them use syscall(3)" seems to
>> remain.
>
> And only 2 applications will continue to use it because no one wants to
> write syscall() wrapper
On Sun, Apr 17, 2016 at 06:42:12PM -0700, H. Peter Anvin wrote:
> On 04/13/16 08:41, Colin Walters wrote:
> > On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote:
> >
> >> It's not possible to read the process umask without also modifying it,
> >> which is what umask(2) does. A library ca
On 04/13/16 08:41, Colin Walters wrote:
> On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote:
>
>> It's not possible to read the process umask without also modifying it,
>> which is what umask(2) does. A library cannot read umask safely,
>> especially if the main program might be multith
On Sun, Apr 17, 2016 at 05:38:24PM -0700, H. Peter Anvin wrote:
> On 04/13/16 19:13, Theodore Ts'o wrote:
> >
> > One other reason to suggest using a /proc file is that you're not at
> > the mercy of the glibc folks to wire up a new system call. (Glibc has
> > been refusing to wire up getrandom(2
On 04/13/16 19:13, Theodore Ts'o wrote:
>
> One other reason to suggest using a /proc file is that you're not at
> the mercy of the glibc folks to wire up a new system call. (Glibc has
> been refusing to wire up getrandom(2), for example. G.)
>
This brings right back up the libinux id
On Wed, Apr 13, 2016 at 11:47:03PM -0400, Steven Rostedt wrote:
> On Wed, 13 Apr 2016 06:59:50 -0700
> Greg KH wrote:
>
>
> > Why not add this to the ktest infrastructure, we strongly encourage that
> > for new syscalls, along with a man page patch.
>
> Do you mean the "selftest infrastructure"
On Apr 13, 2016 2:01 PM, "Mathieu Desnoyers"
wrote:
>
> - On Apr 13, 2016, at 11:39 AM, Mathieu Desnoyers
> mathieu.desnoy...@efficios.com wrote:
>
> > - On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjo...@redhat.com
> > wrote:
> >
> >> v1 -> v2:
> >>
> >> - Use current_umask() instea
On Wed, 13 Apr 2016 06:59:50 -0700
Greg KH wrote:
> Why not add this to the ktest infrastructure, we strongly encourage that
> for new syscalls, along with a man page patch.
Do you mean the "selftest infrastructure"? As I don't see how this
could be used with ktest.
See tools/testing/selftests
On Wed, Apr 13, 2016 at 09:01:25PM +, Mathieu Desnoyers wrote:
> I'm actually discussing 3 separate things here: the umask, sigmask, and
> cpu affinity mask.
The last two are available in /proc//status --- which brings up
the question why not just add umask to /proc//status?
That way the shar
- On Apr 13, 2016, at 11:39 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjo...@redhat.com wrote:
>
>> v1 -> v2:
>>
>> - Use current_umask() instead of current->fs->umask.
>>
>> - Retested it.
>>
>> ---
On Wed, Apr 13, 2016 at 11:41:45AM -0400, Colin Walters wrote:
> On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote:
>
> > It's not possible to read the process umask without also modifying it,
> > which is what umask(2) does. A library cannot read umask safely,
> > especially if the mai
On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote:
> It's not possible to read the process umask without also modifying it,
> which is what umask(2) does. A library cannot read umask safely,
> especially if the main program might be multithreaded.
I assume you just want to do this from
- On Apr 13, 2016, at 8:57 AM, Richard W.M. Jones rjo...@redhat.com wrote:
> v1 -> v2:
>
> - Use current_umask() instead of current->fs->umask.
>
> - Retested it.
>
> --
>
> It's not possible to read the process umask with
On Wed, Apr 13, 2016 at 01:57:50PM +0100, Richard W.M. Jones wrote:
> v1 -> v2:
>
> - Use current_umask() instead of current->fs->umask.
>
> - Retested it.
>
> --
>
> It's not possible to read the process umask without also m
v1 -> v2:
- Use current_umask() instead of current->fs->umask.
- Retested it.
--
It's not possible to read the process umask without also modifying it,
which is what umask(2) does. A library cannot read umask safely,
especia
22 matches
Mail list logo
