Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1427598 > unrolled thread

Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass off_t

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass  off_t Joseph Myers <joseph@codesourcery.com> - 2016-06-21 12:50 +0200
    Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass  off_t Joseph Myers <joseph@codesourcery.com> - 2016-06-23 14:00 +0200

#1427598 — Re: [PATCH 21/27] [AARCH64] ILP32: introduce syscalls that pass off_t

On Tue, 21 Jun 2016, Yury Norov wrote:

>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/fallocate64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/ftruncate.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/ftruncate64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/llseek.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/lseek.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/mmap.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/posix_fadvise.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/posix_fadvise64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pread.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pread64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pwrite.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/pwrite64.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/readahead.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/truncate.c
>  create mode 100644 sysdeps/unix/sysv/linux/aarch64/ilp32/truncate64.c

I don't like how you need so many ilp32 files.

Presumably this is a new convention to be followed for all future ilp32 
ABIs on 64-bit architectures.  Meaning that you should have some sysdeps 
macros to say whether this convention is in use and then make either the 
sysdeps/unix/sysv/linux files, or the .../generic files, or a new 
architecture-independent sysdeps directory, implement that convention.

Note also how Adhemerval recently unified pread / pwrite implementations.  
Adding new files for those functions goes against that unification.

-- 
Joseph S. Myers
joseph@codesourcery.com

[toc] | [next] | [standalone]

#1429728

On Thu, 23 Jun 2016, Yury Norov wrote:

> So for now I think it's simpler to have this ABI in sysdeps, and be in

Of course it goes in sysdeps.  But not architecture-specific sysdeps.  
And "simpler" for initial implementation may not be simpler for future 
maintenance; when there are too many implementations of a function, they 
have a tendency to get out of sync, and to cause trouble for future global 
changes.  There are two plausible options that I see:

* sysdeps/unix/sysv/linux/<some-descriptive-name>, where 
<some-descriptive-name> is an architecture-independent name for the 
relevant ABI feature.

* Have a macro __SOME_ABI_FEATURE in some sysdeps header, and then use 
conditionals on that macro in existing implementations in 
sysdeps/unix/sysv/linux/generic or sysdeps/unix/sysv/linux.

I think the second one is preferable.  If you prefer the first one, you 
should be able to justify it by giving some detailed examples of what the 
different implementations look like and why there is actually nothing 
useful in common between them that would allow shared implementations with 
conditional code.

-- 
Joseph S. Myers
joseph@codesourcery.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web