Re: Sharing of bits/fcntl.h for Linux - some questions

[Roland McGrath <roland at hack dot frob dot com>]

> Should we do this as well for constants where only one architecture is 
> the odd one? Or should the header only contain architecture independent 
> stuff?

We have always had a very strong preference for avoiding this kind of
#ifdef.  I don't think we want to start having exceptions.  It is important
to keep the machine-independent file truly machine-independent.

> 2) There are some values that are different on a few architectures. The 
> Linux kernel <asm-generic/fcntl.h> handles this as following:
> - include a architecture specific file that includes some stuf and can 
> define some values
> - check in the generic file whether the value is defined, e.g.:
> #ifndef O_EXCL
> #define O_EXCL          00000200        /* not fcntl */
> #endif

I think this is fine enough in the abstract.  One caveat is that for some
of the macros (not O_EXCL) we have feature-test macros controlling whether
we define them.  It's a bad idea to create a situation wherein the logic
about what feature-test macros to use is repeated in machine-dependent
files.  In fact, realy nothing at all but the differing bit values should
appear in a machine-dependent file.  So for some cases it may be
appropriate to have the machine-dependent file (optionally) define __O_FOO
instead and have the common file do:

#ifndef __O_FOO
# define _O_FOO		0x1234
#endif

#if defined __USE_FOO || defined __USE_BAR
# define O_FOO		__O_FOO
#endif

> 3) struct flock/flock64 have on SPARC an extra padding.
> 
> struct flock64
>    {
>      short int l_type;	/* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK.	*/
>      short int l_whence;	/* Where `l_start' is relative to (like 
> `lseek').  */
>      __off64_t l_start;	/* Offset where the lock begins.  */
>      __off64_t l_len;	/* Size of the locked area; zero means until EOF.  */
>      __pid_t l_pid;	/* Process holding the lock.  */
>      __ARCH_FLOCK_PAD
>    };
> 
> The Linux kernel adds an __ARCH_FLOCK_PAD with the definition that can 
> be set by an architecture. Should we do the same - or have each 
> architecture have its own copy?

The general answer is that minimizing the duplication is always best.
So in this case, the macro hack is preferable I'd say.


Thanks,
Roland