-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan Cox wrote:
>> continuous allocation are part of the API. It's required by POSIX and
>> provided by Unix since the early days. There are entire code bases out
>> there which depend on this assumption. Linking with code like this,
>> before or after the new version controlled symbol is introduced, will
>> break it.
>
> If your linker is doing its job then you won't be able to link them
> together because they have incompatible assumptions. Not exactly rocket
> science even if it is done a little differently to the usual symbol
> compatibility tests.
No. You still don't appreciate the problem.
Assume I would change code so that newly compiled programs which use
open, socket, etc generate different references which cannot be
satisfied by old runtimes. That and only that is something linkers can
see, linkers deal with symbols and references.
If I would do that and people would recompile their existing code this
*still* does not change the fact that the program behavior would be
changed and the code might break. It can be something as simple as
int fd = open(...);
...
close(fd);
...
close(STDIN_FILENO);
open(...);
The last open is supposed to open a new file with descriptor 0 (i.e.,
STDIN_FILENO). By using non-sequential descriptors this is not guaranteed.
This is nothing you can change with linker magic. It is embedded in the
code. It's behavior *guaranteed* by POSIX and Unix before it for
decades. This isn't anything you can change.
> And the stuff you are trying to put into the kernel is better ? No, its a
> bunch of ugly hacks caused by trying to solve the problem in the wrong
> way and in the wrong place.
Go back 30 years and convince people to not guarantee first-match
allocation of descriptors. Then you can stand up and demand purity.
But just as in many other cases, legacy demands its price. We sometimes
have to pay the price for compatibility and if it isn't high it's worth
it. I don't say the current proposed code is the answer but iff
Davide's unified code does not perform worse than the current code I
don't see the harm since, for instance, extending socket() is in any
case necessary. I mentioned that close_on_exit must be set on open,
else leaks are risked. This will come naturally with a flags parameter
which already takes O_NONSEQFD.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGaBVb2ijCOnn/RHQRAnzGAJwLY3dDc9nl69yFPZfYUr8qbIeXygCfTqMd
u5Jofy3gFB5bWEHdnPtUhJY=
=Jz/g
-----END PGP SIGNATURE-----
-
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]
