As the replacement cannot be made thread-safe, we need to
document this to prevent users from having a false sense
of safety.
* doc/glibc-functions/pipe2.texi (pipe2): mention lack of thread-safety
Signed-off-by: Eric Wong
---
I took the line off the existing documentation for the
similar-in
Eric Blake wrote:
> On 01/25/2012 06:09 PM, Eric Wong wrote:
> > As the replacement cannot be made thread-safe, we need to
> > document this to prevent users from having a false sense
> > of safety.
> >
> > * doc/glibc-functions/pipe2.texi (pipe2): mention lack
#x27;
- ? Digest::MD5->new->addfile(*IN)->hexdigest
- : Digest::SHA1->new->addfile(*IN)->hexdigest);
+ my $dig = Digest->new($meth)->addfile(*IN)->hexdigest;
close IN;
print "$dig $f\n";
}
--
Eric Wong
0 \
+ || strcmp (Fs_type, "fusectl") == 0 \
+ || strcmp (Fs_type, "mqueue") == 0 \
+ || strcmp (Fs_type, "rpc_pipefs") == 0 \
+ || strcmp (Fs_type, "sysfs") == 0\
/* for NetBSD 3.0 */ \
|| strcmp (Fs_type, "kernfs") == 0 \
/* for Irix 6.5 */ \
--
Eric Wong
pipefs") == 0 \
+ || strcmp (Fs_type, "sysfs") == 0\
+ /* FreeBSD, Linux 2.4 */ \
+ || strcmp (Fs_type, "devfs") == 0 \
/* for NetBSD 3.0 */ \
|| strcmp (Fs_type, "kernfs") == 0 \
/* for Irix 6.5 */ \
--
Eric Wong
Jim Meyering wrote:
> Eric Wong wrote:
> > * lib/mountlist.c (ME_DUMMY_0):
> > additional dummy FS names for Linux systems.
> > - "devpts" PTY slave filesystem
> > - "fusectl" control filesystem for FUSE
> > - "mqueue&qu
also noticed "debugfs"
on some systems.
Here is an updated patch with debugfs and devtmpfs:
>From b0904cbd02932009e0b9de568ce4742d27a18e78 Mon Sep 17 00:00:00 2001
From: Eric Wong
Date: Fri, 7 Dec 2012 23:14:34 +
Subject: [PATCH] mountlist: recognize more "dummy" file
Pádraig Brady wrote:
> On 01/28/2013 01:14 PM, Pádraig Brady wrote:
> >On 12/14/2012 04:17 AM, Jim Meyering wrote:
> >>If we're omitting "devfs", then should "devtmpfs" also be omitted?
> >
> >I don't think "devtmpfs" should be marked as dummy
> >as there is storage associated with it.
> >I.E. you
Debian testing (7.0) builds eglibc 2.13 against Linux 2.6.26 features
so it can run as a chroot on older Debian releases.
Debian 7.0 will ultimately use a 3.2 kernel, Debian 6.0 runs 2.6.32.
So I think the highest kernel version Debian can currently build eglibc
against is is 2.6.32 (so it can st
Paul Eggert wrote:
> On 01/29/2013 05:28 PM, Eric Wong wrote:
> > So I think the correct solution would be to check the __ABI_TAG_VERSION
> > in the PT_NOTE section, but I haven't figured out how to do that at
> > runtime... (ref: csu/abi-note.S in glibc source tree).
Paul Eggert wrote:
> On 01/29/2013 06:44 PM, Eric Wong wrote:
> > eglibc on Debian is only configured to only use features available in
> > Linux 2.6.26 at build time. This means statvfs() uses stat() internally
> > regardless of the run-time kernel version[1].
>
>
It turns out this problem was not specific to eglibc or Debian.
glibc has the same issue with stat() being called in statvfs() on
Linux 2.6.36+
Eric Wong wrote:
> Paul Eggert wrote:
> > On 01/29/2013 06:44 PM, Eric Wong wrote:
> > > eglibc on Debian is only configured to
Eric Blake wrote:
> The libvirt project would be very interested in using open_memstream,
> since it is now part of POSIX 2008.
Hi, I realize this thread for open_memstream support in gnulib is now
several years old. Just wondering why it was never completed/merged
into gnulib...
I assume it's
Eric Blake wrote:
> open_memstream still sounds like a nice project for anyone interested in
> implementing, though.
Thanks for the reply, I've also been able to cope without it.
Hopefully somebody has spare cycles pick this up (or more platforms can
just support it natively).
gt; if ((fd < 0 ? stat64 (name, &st) : fstat64 (fd, &st)) < 0)
> return 0;
Thanks for the comments, here is an updated patch with your suggestions
and ChangeLog entry:
--- 8< ----
>From ed01f553461357e6c9ef40efd
- 8< ---
>From 92f694865d0014bffd0069c549c4a6274e2f1430 Mon Sep 17 00:00:00 2001
From: Eric Wong
Date: Fri, 1 Feb 2013 01:55:27 +
Subject: [PATCH] avoid stat/fstat in statvfs/fstatvfs
Delay the use of stat/fstat until stat data is required.
When the kernel returns ST_VALID, stat d
Roland McGrath wrote:
> That looks fine.
>
> > * sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
> > Pass fd to __internal_statvfs instead of calling fstat64.
> > * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
> > Pass fd to __internal_statvfs64 instead of calling fstat64
Roland McGrath wrote:
> Oh, I didn't notice they weren't identical. You're right that it shouldn't
> use plain "Likewise." then. But you could write:
>
> * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
> Likewise for __internal_statvfs64.
>
> > I'm not fan of signing into we
Eric Wong wrote:
> Roland McGrath wrote:
> > Oh, I didn't notice they weren't identical. You're right that it shouldn't
> > use plain "Likewise." then. But you could write:
> >
> > * sysdeps/unix/sysv/linux/fstatvfs64.c
bogomips.org is expiring and .org is unlikely to be affordable
down the line, so it's on yhbt.net for now.
---
It's also available for Tor users at
http://cmogstored.ou63pmih66umazou.onion/
but I guess .onions and Tor aren't as well known as it ought to be...
users.txt | 2 +-
1 file changed,
Bruno Haible wrote:
> Hi Marc, Ben,
>
> I need your expertise regarding data structures.
>
> Assume a program has a signal handler, which needs to share some data
> structure with the rest of the program.
>
> There are two cases:
>
> (A) Assume that the program is single-threaded.
> Then i
Bruno Haible wrote:
> Hi Eric,
>
> Eric Wong wrote:
> > I would've recommended just using a pipe, socket or eventfd;
>
> How would setting up a pipe or eventfd help with a communication
> problem between threads in the same process? I thought these were
> for
Bruno Haible wrote:
> Eric Wong wrote:
> > > How would setting up a pipe or eventfd help with a communication
> > > problem between threads in the same process? I thought these were
> > > for communication between processes.
> >
> > The "self-p
This avoid conflicts with FreeBSD headers when using the
"freebsd-glue" package on Debian GNU/kFreeBSD
Reproducible with:
./configure LIBS=-lfreebsd-glue CFLAGS=-I/usr/include/freebsd
* lib/argp-parse.c (struct argp_group): rename from struct group
---
Now I'm stuck on another failure, anothe
Note: things work fine without freebsd-glue, but I wanted to
transparently enable FreeBSD sendfile on cmogstored.
I got another failure after fixing the argp "struct group" conflict.
Also using:
./configure LIBS=-lfreebsd-glue CFLAGS=-I/usr/include/freebsd
(Note: this is not that important for
cmogstored has used gnulib since the beginning in 2012 to support
GNU/Linux, FreeBSD, and GNU/kFreeBSD. cmogstored is currently
included in the FreeBSD ports collection, but developed primarily
on GNU/Linux.
Signed-off-by: Eric Wong
---
users.txt | 1 +
1 file changed, 1 insertion(+)
diff
26 matches
Mail list logo
