On Sun, 3 Jun 2007, Ingo Molnar wrote:
> > #define FD_UNSEQ_BASE (1U << 28)
> > #define FD_UNSEQ_ALLOC (1U << 30)
>
> i'm wondering, why not use (1 << 30) both as the base and as the flag?
> That would make integration of the new fd space 'seemless' in terms of
> dup2() use.
There are two behaviours to handle. One is the standard dup2() one, where
you pass a "newfd" by saying that you want "oldfd" exactly on top of
"newfd". With the new sys_dup2() you can pass an fd inside the
unsequential area, and have the same behviour of the legacy dup2().
The other one, unique to unsequential fds, is asking the kernel to just
allocate a free one from the unsequential map, whatever it is.
So we need a flag, that is "far enough" from the unsequential map
allocation space. I was actually thinking of moving FD_UNSEQ_BASE down to
(1 << 27) or (1 << 26), and leave some more space for flags.
128M or 64M of descriptors should be enough for the legacy, sequential fd
allocator ;)
> > It'd be possible to add a new O_UNSEQFD flag to open(2) and make
> > sys_open() to allocate the new descriptor inside the unsequential map.
>
> yeah, please do that now - lets not leave any incomplete areas. We've
> too often made the mistake of not pushing through new APIs consistently
> enough.
Will do today.
> I'd also suggest a new sys_socket2() call that takes a 'flags' parameter
> as well - because one primary user of this facility will be networking
> servers. (O_UNSEQFD would make sense for it and O_NDELAY - currently
> network apps that want to set O_NDELAY need to do it with an extra
> fcntl() - while they could already indicate this in the sys_socket()
> call, if it were closer to sys_open() semantics)
Makes sense for me, since sys_socket() is the primary source of fds
wherever you have fd-crowded applications. And those definitely aren't
using select() ;)
I seem to remember, that either you or Uli, talked about task-private fds,
although I do not remember the context. A close-on-fork flag?
- Davide
-
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]
