Messages in this thread | | | Date | Thu, 7 Jun 2007 00:19:32 +0100 | From | Alan Cox <> | Subject | Re: [patch 7/8] fdmap v2 - implement sys_socket2 |
| |
> > prctl(PR_SPARSEFD, 1); > > > > to turn on sparse fd allocation for a process ? > > There was a little discussion where I tried to whisper something similar, > but Linus and Uli shot me :) - with good reasons IMO. > You may link to runtimes that are not non-sequentialfd aware, and will > break them.
Linking to the correct version of a libary and getting the library versioning right is not rocket science and isn't a sane excuse. Its no different to the stdio to large fd migration issues with many Unixen and they all coped just fine.
Really all this new syscall hackery stuff is just too ugly to live. If you use the prctl then yes we have a bit of library versioning to worry about for the odd library that cares but thats a once over thing. The crappy zillion extra syscalls we have to support for years and years just to save a little bit of userspace work.
At its most moronic its no different to 32 and 64bit binary linking - and the gnu tools manage to cope with stopping me linking a 32bit app to a 64bit lib and vice versa just fine, so I'm sure they can cope the same way with sparse fd safe/non sparese fd safe libraries
- 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/
| |