|
|
Subscribe / Log in / New account

Backwards compatibility at any cost?

Backwards compatibility at any cost?

Posted Nov 8, 2024 20:25 UTC (Fri) by rweikusat2 (subscriber, #117920)
In reply to: Backwards compatibility at any cost? by taladar
Parent article: The trouble with struct sockaddr's fake flexible array

The chances that people will modify all existing software ever developed for the BSD sockets API just because someone thinks he has a better idea for representing network addresses are - politely put - not very great.

:-)


to post comments

Backwards compatibility at any cost?

Posted Nov 9, 2024 8:38 UTC (Sat) by smurf (subscriber, #17840) [Link]

IMHO the only incompatibility is that for addresses smaller than 16 bytes the kernel will no longer zero out the padding when it copies an address to userspace / require the padding to even exist when it reads an address.

Everything else should literally stay the same. I have no idea how many programs go splat because their address padding is no longer overwritten but if the number is nonzero then a compatibility mode can be added to the place where the address is copied to userspace. Not spread across the whole of the kernel.

Backwards compatibility at any cost?

Posted Nov 14, 2024 5:40 UTC (Thu) by dvdeug (guest, #10998) [Link] (2 responses)

You can always have a BSD sockets API translation layer. It could be constrained to libc, but the kernel would probably support those system calls indefinitely. But that wouldn't stop a new set of system calls and the old system calls being wrappers around the new system calls.

Backwards compatibility at any cost?

Posted Nov 14, 2024 7:01 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

The Sockets API isn't the problem. It happens not to embed a sockaddr in anything, much less in the middle of another struct.

Backwards compatibility at any cost?

Posted Nov 14, 2024 21:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

It kinda is...

A lot of the sockets API needs to be rewritten. It needs to support Happy Eyeballs, it needs to expose the DNS data explicitly (TXT queries, etc.), it needs to be able to deal with changing/multiple addresses for the bound sockets, etc.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds