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 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:
> > >
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 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 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
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 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 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
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
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 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.
>
>
11 matches
Mail list logo
