On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote:
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
>
> I'd l
On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner wrote:
>
> On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote:
> > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote:
> >
> > > If you can't tell from userspace that a file has data in it other
> > > than by calling read() on it,
On Fri, Feb 12, 2021 at 12:38 AM Greg KH wrote:
>
> Why are people trying to use copy_file_range on simple /proc and /sys
> files in the first place? They can not seek (well most can not), so
> that feels like a "oh look, a new syscall, let's use it everywhere!"
> problem that userspace should no
On Fri, Feb 12, 2021 at 7:45 AM Greg KH wrote:
>
> On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > On Fri, Feb 12, 2021 at 12:38 AM Greg KH wrote:
> > >
> > > Why are people trying to use copy_file_range on simple /proc and /sys
> > >
On Fri, Feb 12, 2021 at 8:28 AM Greg KH wrote:
>
> On Fri, Feb 12, 2021 at 07:59:04AM -0800, Ian Lance Taylor wrote:
> > On Fri, Feb 12, 2021 at 7:45 AM Greg KH wrote:
> > >
> > > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > >
On Fri, Feb 12, 2021 at 3:03 PM Dave Chinner wrote:
>
> On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote:
> > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote:
> > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH
> > > wrote:
> > >
Thanks for the note. I'm not a kernel developer, but to me this
sounds like a kernel bug. It seems particularly unfortunate that
copy_file_range returns 0 in this case. From the perspective of the
Go standard library, what we would need is some mechanism to detect
when the copy_file_range system
On Sun, Jun 15, 2014 at 12:14 PM, H. Peter Anvin wrote:
>
> If it doesn't, then you incur an additional indirection penalty. The strong
> __vdso symbol allows the libc wrapper to fall back to the vdso
> implementation, the weak symbol allows three to be no wrapper at all. This
> is good.
>
>
time my program is always going to be
linked with the gettimeofday in libc.so, which will in turn call the
gettimeofday in the vDSO.
Am I missing something that makes the definition of gettimeofday with
version LINUX_2.6 in the vDSO useful?
Ian
> On June 15, 2014 12:22:17 PM PDT, Ian Lance Ta
On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen wrote:
>
> I haven't looked into this in detail, but my initial assumption would
> be that it wouldn't be useful to add new vdso interfaces just for Go.
> After all would you really want to force ever Go user to upgrade their
> kernel just to get fast fi
On Mon, Jun 16, 2014 at 7:38 AM, Andi Kleen wrote:
>> I think this issue started when some of the Go developers questioned
>> why the kernel needed to provide a very complex interface--parsing an
>> ELF shared shared library--for very simple functionality--looking up
>> the address of a magic func
11 matches
Mail list logo
