On Wed, Mar 29 2006, Andrew Morton wrote:
> > Besides, they should
> > never be signed, if you do bitmasks and shifting on them: "int" is
> > strictly worse than "unsigned" when we're talking flags.
>
> Sure, but is there any gain in making flags 64-bit on 64-bit machines when
> we cannot use more than 32 bits in there anyway?
unsigned int seems fine to me.
> > Right now "flags" doesn't do anything at all, and you should just pass in
> > zero.
>
> In that case perhaps we should be enforcing flags==0 so that future
> flags-using applications will reliably fail on old flags-not-understanding
> kernels.
>
> But that won't work if we later define a bit in flags to mean "behave like
> old kernels used to". So perhaps we should require that bits 0-15 of
> `flags' be zero and not care about bits 16-31.
>
> IOW: it might be best to make `flags' just go away, and add new syscalls in
> the future as appropriate.
Not if flags == 0 maintains the same behaviour. The only flag I can
think of right now is the 'move' or 'gift' flag, meaning that the caller
wants to migrate pages from the pipe instead of copying them. I'd
imagine we'd get that in way before 2.6.17 anyways, so I think we're
fine.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
