Provide socket option definitions

[loganek]

Hi, I've noticed there's no definition in __header_sys_socket.h for socket options. Is that intentional? I see other definitions (e.g. AF_INET) are already added to the header, but I can't find it anywhere in the WASI spec (so I'm not sure why e.g. AF_INET is defined as 1, even though in linux headers it's 3). I can also see SO_TYPE being already included, but that's the only option that's available (and is set to 3, which matches Linux headers).

If lack of those definitions is not intentional, I can provide a PR for that; however, I'm not sure what numbers should be assigned to a specific definition - is there any specification already? (as I said, I couldn't find one for AF_INET either).

Many thanks

[sunfishcode]

It has always been envisioned that WASI would be adding sockets support at some point. And there is now a wasi-sockets proposal which is working towards adding it. A PR to add more of these values would be welcome.

The values of AF_INET, SO_TYPE and related constants are not standardized in POSIX, IANA, or anywhere else, they aren't encoded in protocols, and I'm not aware of them being hard-coded in applications. And in practice, some of these values do differ among popular OS's. Consequently, I don't think it's necessary to match Linux's specific values here.

The wasi-sockets API bindings will define its own constants corresponding to these enums, however I believe wasi-libc will want to continue to define its own values, so that it can have a stable ABI.

So I think there are two main options here. We could add more values to __header_sys_socket.h. Or, we could switch over to just enabling the definitions in musl's sys/socket.h instead (in libc-top-half/musl/include/sys/socket.h in the tree). Using musl's definitions would be nice as we wouldn't need to maintain as much of this code ourselves. My main hesitation is that musl's values do match Linux's values, which could lead code to forget to translate these values in some places. But maybe that's not something we need to worry about. Does anyone else have an opinion here?

[loganek]

Thanks a lot for the reply. I see the concern you raised about the values matching Linux's values. My preference would be to keep the code as close to the original one (i.e. musl's one) as possible to keep cherry-picking process as simple as possible (although from what I've seen in the code and in discussions around, it's a bit painful now anyway). Let's see if others have strong opinions around that; once we'll reach the conclusion, I'm happy to prepare a PR for that.

[sunfishcode]

I can also add that some of the considerations have changed since this code was first developed. __header_sys_socket.h was written at a time when the WASI bindings did have a stable-ish C ABI with things like __WASI_FILETYPE_SOCKET_DGRAM and so on, and it looked like we wanted wasi-libc to use those values in its own public ABI. Now, WASI is moving to an IDL with subtyping etc., so it makes sense to have separation.

Also, some of the reasons cherry-picking is a bit painful is that we initially had a lot of open questions and generally wanted to limit our backwards-compatibility surface area, to give ourselves the flexibility to evolve the platform. That's has had some value, however I think we now have more clarity on what areas need that flexibility, and what areas don't. We've been starting to enable more of musl's code for various things, and I think it makes sense to continue that in many areas.

So I'm thinking we should switch to musl's code here. The risk of code forgetting to translate between wasi-libc values and Linux values is real, but I think it's less important here.