public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Yury Norov <ynorov@caviumnetworks.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH 4/4] Consolidate posix_fadvise implementations
Date: Tue, 23 Aug 2016 19:29:00 -0000	[thread overview]
Message-ID: <b2a16370-a017-8334-b5af-a6fe763c2dbe@linaro.org> (raw)
In-Reply-To: <20160822150819.GC15745@yury-N73SV>

Thanks for the reviews, comments below.

On 22/08/2016 12:08, Yury Norov wrote:
>> diff --git a/posix/tst-posix_fadvise-common.c b/posix/tst-posix_fadvise-common.c
>> new file mode 100644
>> index 0000000..6670835
>> --- /dev/null
>> +++ b/posix/tst-posix_fadvise-common.c
>> @@ -0,0 +1,113 @@
>> +/* Common posix_fadvise tests definitions.
>> +   Copyright (C) 2016 Free Software Foundation, Inc.
>> +   This file is part of the GNU C Library.
>> +
>> +   The GNU C Library is free software; you can redistribute it and/or
>> +   modify it under the terms of the GNU Lesser General Public
>> +   License as published by the Free Software Foundation; either
>> +   version 2.1 of the License, or (at your option) any later version.
>> +
>> +   The GNU C Library is distributed in the hope that it will be useful,
>> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> +   Lesser General Public License for more details.
>> +
>> +   You should have received a copy of the GNU Lesser General Public
>> +   License along with the GNU C Library; if not, see
>> +   <http://www.gnu.org/licenses/>.  */
>> +
>> +#include <fcntl.h>
>> +#include <sys/types.h>
>> +#include <sys/stat.h>
>> +#include <unistd.h>
>> +
>> +static void do_prepare (void);
>> +#define PREPARE(argc, argv)     do_prepare ()
>> +static int do_test (void);
>> +#define TEST_FUNCTION           do_test ()
>> +
>> +#include <test-skeleton.c>
>> +
>> +static char *temp_filename;
>> +static int temp_fd;
>> +static char fifoname[] = "/tmp/tst-posix_fadvise-fifo-XXXXXX";
>> +static int fifofd;
>> +
>> +static void
>> +do_prepare (void)
>> +{
>> +  temp_fd = create_temp_file ("tst-posix_fadvise.", &temp_filename);
>> +  if (temp_fd == -1)
>> +    {
>> +      printf ("cannot create temporary file: %m\n");
>> +      exit (1);
>> +    }
>> +
>> +  if (mktemp (fifoname) == NULL)
>> +    { 
> 
> Trailing whitespace

Ack, I will fix  it.

> 
>> +      printf ("%s: cannot generate temp file name: %m\n", __func__);
>> +      exit (1);
>> +    }
>> +  add_temp_file (fifoname);
>> +
>> +  if (mkfifo (fifoname, S_IWUSR | S_IRUSR) != 0)
>> +    {
>> +      printf ("%s: cannot create fifo: %m\n", __func__);
>> +      exit (1);
>> +    }
>> +
>> +  fifofd = open (fifoname, O_RDONLY | O_NONBLOCK);
>> +  if (fifofd == -1)
>> +    {
>> +      printf ("%s: cannot open fifo: %m\n", __func__);
>> +      exit (1);
>> +    }
>> +}
>> +
>> +#define FAIL(str) \
>> +  do { printf ("error: %s (line %d)\n", str, __LINE__); return 1; } while (0)
>> +
> 
> You don't fit into a single line anyway. Why don't you make it nicer?

Right, I think the snippet below should be more readable.  I will change it.

#define FAIL(str) \
  do { \
    printf ("error: %s (line %d)\n", str, __LINE__); \
    return 1; \
  } while (0)

>> +/* Effectivelly testing posix_fadvise is hard because side effects are not
>> +   observed without checking either performance or any kernel specific
>> +   supplied information.  Also, the syscall is meant to be an advisory,
>> +   so kernel is free to use these information in which way it seems as
>> +   fit (even ignoring it).
>> +   
> 
> Trailing whitespaces
> 

Ack.

>> diff --git a/sysdeps/unix/sysv/linux/posix_fadvise.c b/sysdeps/unix/sysv/linux/posix_fadvise.c
>> index 093d707..869a642 100644
>> --- a/sysdeps/unix/sysv/linux/posix_fadvise.c
>> +++ b/sysdeps/unix/sysv/linux/posix_fadvise.c
>> @@ -22,27 +22,46 @@
>>  /* Advice the system about the expected behaviour of the application with
>>     respect to the file associated with FD.  */
>>  
>> +#ifndef __OFF_T_MATCHES_OFF64_T
>> +
>> +/* Both arm and powerpc implements fadvise64_64 with last 'advise' argument
>> +   just after 'fd' to avoid the requirement of implementing 7-arg syscalls.
>> +   ARM also defines __NR_fadvise64_64 as __NR_arm_fadvise64_64.
>> +
>> +   tile requires __ASSUME_ALIGNED_REGISTER_PAIRS but implements the 32-bit
>> +   fadvise64_64 without the padding 0 after fd.
>> +
>> +   s390 implements fadvice64_64 using a specific struct with arguments
>> +   packed inside.  This is the only implementation handled in arch-specific
>> +   code.  */
> 
> Are you sure it will be the only implementation forever, and comment
> will be valid too?

The comment is meant to only describe supported architectures at the
time the patch was created.  Any other port that either deviates
from current approach or uses a already describe one should update
this description.

>> diff --git a/sysdeps/unix/sysv/linux/posix_fadvise64.c b/sysdeps/unix/sysv/linux/posix_fadvise64.c
>> index 6d10558..15e08b7 100644
>> --- a/sysdeps/unix/sysv/linux/posix_fadvise64.c
>> +++ b/sysdeps/unix/sysv/linux/posix_fadvise64.c
>> @@ -17,32 +17,54 @@
>>  
>>  #include <errno.h>
>>  #include <fcntl.h>
>> -#include <sysdep.h>
>> +#include <shlib-compat.h>
>>  
>>  int __posix_fadvise64_l64 (int fd, off64_t offset, off64_t len, int advise);
>> -int __posix_fadvise64_l32 (int fd, off64_t offset, size_t len, int advise);
>> +
>> +/* Both arm and powerpc implements fadvise64_64 with last 'advise' argument
>> +   just after 'fd' to avoid the requirement of implementing 7-arg syscalls.
>> +   ARM also defines __NR_fadvise64_64 as __NR_arm_fadvise64_64.
>> +
>> +   tile requires __ASSUME_ALIGNED_REGISTER_PAIRS but implements the 32-bit
>> +   fadvise64_64 without the padding 0 after fd.
>> +
>> +   s390 implements fadvice64_64 using a specific struct with arguments
>> +   packed inside.  This is the only implementation handled in arch-specific
>> +   code.  */
>> +
>> +#ifdef __ASSUME_FADVISE64_64_NO_ALIGN
>> +# undef __ALIGNMENT_ARG
>> +# define __ALIGNMENT_ARG
>> +#endif
>> +
>> +#ifndef __NR_fadvise64_64
>> +# define __NR_fadvise64_64 __NR_fadvise64
>> +#endif
>>  
>>  /* Advice the system about the expected behaviour of the application with
>>     respect to the file associated with FD.  */
>> -
> 
> Is it necessary to remove this line. You don't do so elsewhere..

Ack, I will add it.

  reply	other threads:[~2016-08-23 19:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-19 14:42 [PATCH 0/4] Linux fallocate, posix_fallocate, and posix_fadvise consolidation Adhemerval Zanella
2016-08-19 14:42 ` [PATCH 2/4] Consolidate fallocate{64} implementations Adhemerval Zanella
2016-08-22 15:14   ` Yury Norov
2016-08-23 19:21     ` Adhemerval Zanella
2016-08-19 14:42 ` [PATCH 4/4] Consolidate posix_fadvise implementations Adhemerval Zanella
2016-08-22 15:08   ` Yury Norov
2016-08-23 19:29     ` Adhemerval Zanella [this message]
2016-08-23 20:00       ` Yury Norov
2016-08-24 14:29         ` Adhemerval Zanella
2016-08-24  3:53   ` Yury Norov
2016-08-24 14:40     ` Adhemerval Zanella
2016-09-25 10:42   ` Yury Norov
2016-09-26 19:44     ` Adhemerval Zanella
2016-08-19 14:42 ` [PATCH 1/4] Add INTERNAL_SYSCALL_CALL Adhemerval Zanella
2016-08-22 15:28   ` Yury Norov
2016-08-23 19:16     ` Adhemerval Zanella
2016-08-23 19:20       ` Yury Norov
2016-08-19 14:42 ` [PATCH 3/4] Consolidate posix_fallocate{64} implementations Adhemerval Zanella
2016-08-22 14:35   ` Yury Norov
2016-08-23 19:22     ` Adhemerval Zanella
2016-08-22 14:31 ` [PATCH 0/4] Linux fallocate, posix_fallocate, and posix_fadvise consolidation Yury Norov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b2a16370-a017-8334-b5af-a6fe763c2dbe@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=ynorov@caviumnetworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).