search for: pipefd

...> diff --git a/usr/klibc/arch/arm64/pipe.c b/usr/klibc/arch/arm64/pipe.c > new file mode 100644 > index 0000000..f10a69e > --- /dev/null > +++ b/usr/klibc/arch/arm64/pipe.c > @@ -0,0 +1,10 @@ > +#include <unistd.h> > + > +#ifndef __NR_pipe > + > +int pipe(int pipefd[2]) > +{ > + return pipe2(pipefd, 0); > +} > + > +#endif /* __NR_pipe */ This is a generic routine, right? It should be part of the generic ersatz functions, no? -hpa

....c =================================================================== --- linux-2.6-lguest.orig/Documentation/lguest/lguest.c 2007-04-05 16:13:08.000000000 -0400 +++ linux-2.6-lguest/Documentation/lguest/lguest.c 2007-04-05 16:16:31.000000000 -0400 @@ -328,15 +328,15 @@ static void wake_parent(int pipefd, stru for (;;) { fd_set rfds = devices->infds; + int ignorefd; select(devices->max_infd+1, &rfds, NULL, NULL, NULL); - if (FD_ISSET(pipefd, &rfds)) { - int ignorefd; - if (read(pipefd, &ignorefd, sizeof(ignorefd)) == 0) - exit(0); - FD_CLR(ignorefd, &dev...

....c =================================================================== --- linux-2.6-lguest.orig/Documentation/lguest/lguest.c 2007-04-05 16:13:08.000000000 -0400 +++ linux-2.6-lguest/Documentation/lguest/lguest.c 2007-04-05 16:16:31.000000000 -0400 @@ -328,15 +328,15 @@ static void wake_parent(int pipefd, stru for (;;) { fd_set rfds = devices->infds; + int ignorefd; select(devices->max_infd+1, &rfds, NULL, NULL, NULL); - if (FD_ISSET(pipefd, &rfds)) { - int ignorefd; - if (read(pipefd, &ignorefd, sizeof(ignorefd)) == 0) - exit(0); - FD_CLR(ignorefd, &dev...

...nging interface %s up", devname); + + if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0) + err(1, "getting hw address for %s", devname); + + memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6); +} + +/* We send lguest_add signals while input is pending: avoids races. */ +static void wake_parent(int pipefd, struct devices *devices) +{ + int parent = getppid(); + nice(19); + + set_fd(pipefd, devices); + + for (;;) { + fd_set rfds = devices->infds; + + select(devices->max_infd+1, &rfds, NULL, NULL, NULL); + if (FD_ISSET(pipefd, &rfds)) { + int ignorefd; + if (read(pipefd, &igno...

...nging interface %s up", devname); + + if (ioctl(fd, SIOCGIFHWADDR, &ifr) != 0) + err(1, "getting hw address for %s", devname); + + memcpy(hwaddr, ifr.ifr_hwaddr.sa_data, 6); +} + +/* We send lguest_add signals while input is pending: avoids races. */ +static void wake_parent(int pipefd, struct devices *devices) +{ + int parent = getppid(); + nice(19); + + set_fd(pipefd, devices); + + for (;;) { + fd_set rfds = devices->infds; + + select(devices->max_infd+1, &rfds, NULL, NULL, NULL); + if (FD_ISSET(pipefd, &rfds)) { + int ignorefd; + if (read(pipefd, &igno...

...est"); + return fd; +} + +static void set_fd(int fd, struct device_list *devices) +{ + FD_SET(fd, &devices->infds); + if (fd > devices->max_infd) + devices->max_infd = fd; +} + +/* We send lguest_add signals while input is pending: avoids races. */ +static void wake_parent(int pipefd, struct device_list *devices) +{ + nice(19); + + set_fd(pipefd, devices); + + for (;;) { + fd_set rfds = devices->infds; + + select(devices->max_infd+1, &rfds, NULL, NULL, NULL); + if (FD_ISSET(pipefd, &rfds)) { + int ignorefd; + if (read(pipefd, &ignorefd, sizeof(ignorefd)...

...est"); + return fd; +} + +static void set_fd(int fd, struct device_list *devices) +{ + FD_SET(fd, &devices->infds); + if (fd > devices->max_infd) + devices->max_infd = fd; +} + +/* We send lguest_add signals while input is pending: avoids races. */ +static void wake_parent(int pipefd, struct device_list *devices) +{ + nice(19); + + set_fd(pipefd, devices); + + for (;;) { + fd_set rfds = devices->infds; + + select(devices->max_infd+1, &rfds, NULL, NULL, NULL); + if (FD_ISSET(pipefd, &rfds)) { + int ignorefd; + if (read(pipefd, &ignorefd, sizeof(ignorefd)...

...rnel, and only returns after the specified timeout - to the point that some `sleep()` with sub-second precision implementations do just that on systems that lack `usleep()`. With `select()` in your capture posting an array of FDs `[7 10]` I'd say it is the parent loop, and one of those is the `pipefd` and another is the FD for socket connection to talk to a particular child on the other side of the pipe. Here I must guess that either the `pselect6()` implementation behaves differently which would be surprising after decades worth of expected behavior, or that it for some reason decides that th...

...rnel, and only returns after the specified timeout - to the point that some `sleep()` with sub-second precision implementations do just that on systems that lack `usleep()`. With `select()` in your capture posting an array of FDs `[7 10]` I'd say it is the parent loop, and one of those is the `pipefd` and another is the FD for socket connection to talk to a particular child on the other side of the pipe. Here I must guess that either the `pselect6()` implementation behaves differently which would be surprising after decades worth of expected behavior, or that it for some reason decides that th...

...diff -ur rsync-2.5.6/pipe.c rsync-2.5.6-filtered/pipe.c --- rsync-2.5.6/pipe.c 2002-04-08 09:39:56.000000000 +0200 +++ rsync-2.5.6-filtered/pipe.c 2003-11-16 13:20:34.000000000 +0100 @@ -146,3 +146,90 @@ } +pid_t run_filter(char *command[], int out, int *pipe_to_filter) +{ + pid_t pid; + int pipefds[2]; + extern int blocking_io; + + if (verbose >= 2) { + print_child_argv(command); + } + + if (pipe(pipefds) < 0) { + rprintf(FERROR, "pipe: %s\n", strerror(errno)); + exit_cleanup(RERR_IPC); + } + + pid = fork(); + if (pid == -1) { + rprintf(FERROR, "fork: %s\n", st...

The previous code: fcntl (fd, F_SETFL, O_NONBLOCK) was technically incorrect, because it would have reset any other flags on the file descriptor. Thanks: Eric Blake --- bootstrap | 1 + daemon/inotify.c | 6 ++++-- lib/conn-socket.c | 21 +++++++++++---------- m4/.gitignore | 9 +++++++++ 4 files changed, 25 insertions(+), 12 deletions(-) diff --git a/bootstrap b/bootstrap

...sr/klibc/arch/arm64/pipe.c > > new file mode 100644 > > index 0000000..f10a69e > > --- /dev/null > > +++ b/usr/klibc/arch/arm64/pipe.c > > @@ -0,0 +1,10 @@ > > +#include <unistd.h> > > + > > +#ifndef __NR_pipe > > + > > +int pipe(int pipefd[2]) > > +{ > > + return pipe2(pipefd, 0); > > +} > > + > > +#endif /* __NR_pipe */ > > This is a generic routine, right? It should be part of the generic > ersatz functions, no? Thanks, I've moved pipe to the generic set. Cheers, -- Steve

...pilable without the rest of the btrfs-progs + * source distribution. + */ +#if BTRFS_FLAT_INCLUDES +#include "send-utils.h" +#include "send-stream.h" +#else +#include <btrfs/send-utils.h> +#include <btrfs/send-stream.h> +#endif /* BTRFS_FLAT_INCLUDES */ + +static int pipefd[2]; +struct btrfs_ioctl_send_args io_send = {0, }; +static char *subvol_path; +static char *root_path; + +struct recv_args { + char *full_subvol_path; + char *root_path; +}; + +void usage(int error) +{ + printf("send-test <btrfs root> <subvol>\n"); + if (error) + exit(error);...

.... This should cause guestunmount - * to exit. It should exit with status code _2_ because we gave it - * a mountpoint which isn't a FUSE mountpoint. + * to exit. It should exit with status code _3_ because we gave it + * a directory which isn't a FUSE mountpoint. */ close (pipefd[1]); @@ -117,10 +117,10 @@ main (int argc, char *argv[]) perror ("waitpid"); exit (EXIT_FAILURE); } - if (!WIFEXITED (status) || WEXITSTATUS (status) != 2) { + if (!WIFEXITED (status) || WEXITSTATUS (status) != 3) { char status_string[80]; - fprintf (stderr, &qu...

Since the first patch: - The program is now called 'guestunmount'. - I tested the --fd option and it appears to work. - You can now control retries / quiet. - Revised man pages. - Includes tests. I'm just running through the automated tests now. Rich.

...matched the 'heartbeat at localhost' UPSNAME we were launched to process 0.000060 [D1] parse_at: processing START-TIMER 0.000151 [D1] Keeping stderr open due to debug verbosity 8 0.000195 Timer daemon started 0.000204 [D2] Timer daemon waiting for connections on pipefd 10 0.250325 [D3] new connection on fd 7 0.250377 New timer: heartbeat-failure-timer (660 seconds) 0.250423 [D1] Exiting upssched (CLI process) 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT command the 'heartbeat at localhost' we were launched...

...matched the 'heartbeat at localhost' UPSNAME we were launched to process 0.000060 [D1] parse_at: processing START-TIMER 0.000151 [D1] Keeping stderr open due to debug verbosity 8 0.000195 Timer daemon started 0.000204 [D2] Timer daemon waiting for connections on pipefd 10 0.250325 [D3] new connection on fd 7 0.250377 New timer: heartbeat-failure-timer (660 seconds) 0.250423 [D1] Exiting upssched (CLI process) 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT command the 'heartbeat at localhost' we were launched...

...matched the 'heartbeat at localhost' UPSNAME we were launched to process 0.000060 [D1] parse_at: processing START-TIMER 0.000151 [D1] Keeping stderr open due to debug verbosity 8 0.000195 Timer daemon started 0.000204 [D2] Timer daemon waiting for connections on pipefd 10 0.250325 [D3] new connection on fd 7 0.250377 New timer: heartbeat-failure-timer (660 seconds) 0.250423 [D1] Exiting upssched (CLI process) 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT command the 'heartbeat at localhost' we were launched...

...matched the 'heartbeat at localhost' UPSNAME we were launched to process 0.000060 [D1] parse_at: processing START-TIMER 0.000151 [D1] Keeping stderr open due to debug verbosity 8 0.000195 Timer daemon started 0.000204 [D2] Timer daemon waiting for connections on pipefd 10 0.250325 [D3] new connection on fd 7 0.250377 New timer: heartbeat-failure-timer (660 seconds) 0.250423 [D1] Exiting upssched (CLI process) 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT command the 'heartbeat at localhost' we were launched...

...fter the specified timeout - to the > point that some `sleep()` with sub-second precision implementations do just > that on systems that lack `usleep()`. > > With `select()` in your capture posting an array of FDs `[7 10]` I'd say > it is the parent loop, and one of those is the `pipefd` and another is the > FD for socket connection to talk to a particular child on the other side of > the pipe. > > Here I must guess that either the `pselect6()` implementation behaves > differently which would be surprising after decades worth of expected > behavior, or that it fo...