On Wed, 9 Oct 2002, Rik van Riel wrote:
> On Wed, 9 Oct 2002, Andreas Dilger wrote:
> > On Oct 09, 2002 10:14 -0400, Robert Love wrote:
> > > On Wed, 2002-10-09 at 10:10, Marco Colombo wrote:
> > >
> > > > > #define O_NOFOLLOW 0400000 /* don't follow links */
> > > > > #define O_NOFOLLOW 0x20000 /* don't follow links */
> > >
> > > No need. See for example O_NOFOLLOW right above. Each architecture can
> > > do has it pleases (I wish otherwise, but...).
> >
> > I would say - if you are picking a new flag that doesn't need to have
> > compatibility with any platform-specific existing flag, simply set them
> > all high enough so that they are the same on all platforms.
>
> Doesn't really matter, you can't run x86 binaries on MIPS so
> you need to recompile anyway.
>
> Source level compatibility is enough for flags like this.
>
> regards,
>
> Rik
>
True, but either you include kernel headers from user apps, or wait for
glibc (or [whatever]libc) to catch up, or do something like this:
#define O_STREAMING 04000000
fd = open(file, ... | O_STREAMING);
(quoted directly from one of Robert's messages).
The latter is broken on MIPS, and requiring either glibc headers or the
programmer to handle different archs is unfortunate. One of the biggest
advantages of O_STREAMING is that is it's simple and elegant to integrate
it into existing apps: let's make it even easier by choosing the same
value, so that the above C is the right thing.
Besides, not all the world is C. I don't expect, say, Perl or Python to
support Linux O_STREAMING on their POSIX modules. Perl does pass flags to
open(2) untouched (I haven't tested Python yet), but right now I have to:
- wait for an official Perl update that supports O_STREAMING;
- test explicitly for different archs in my perl program in order
to choose the right O_STREAMING value (or hack system modules to do
the same);
- forget about portability on my Perl script (which is somewhat worse than
doing that same for a C program: one of the goals of using Perl *is*
portability).
Note that having different O_NOFOLLOW (or even O_CREAT) values is less
annoying, since I expect any language that allows me to pass flags to
open(2) (or fcntl(2)) to define those as macros (constants, subroutines
or whatever).
In the end, I see we can choose different values, but why should we?
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:36 EST