Hacker News new | ask | show | jobs
by candiodari 831 days ago
> There's some ideological benefits, but plan9 creates a mess of implicit text protocols, ugly string handling, syscall storms and memory inefficiencies.

On the other hand, linux ioctl and syscalls have infinite binary structs you need to know (and cannot let the compiler reorder fields in), which then doesn't make cross-platform development any easier.
2 comments
arghwhat 831 days ago
Having to know structs is not really an issue - you also need to know text formats, JSON schemas, what not.

Re-ordering of structs is always forbidden with the binary format being strictly specified, so there's nothing to worry about there. Can't exactly shuffle bytes in a text format either, and plan9 control strings tend to have positional arguments.

The current structs do leave something to be desired though.

link
akdev1l 831 days ago
Structured json data that you mentioned does allow to “shuffle bytes”

It doesn’t matter which order the client sends {“a”: 1, “b”: 2 }, it’s one object with “a” and “b” regardless

link
arghwhat 831 days ago
Do the same to a JSON array.

Position having meaning is a common part of most data representations, not something specific to structs. If you need to, you can also engineer order independence in structs with arrays of type and value unions, but there's no need to as the order has never been a problem.

link
candiodari 831 days ago
Really? The issue is that those structs don't cross-compile correctly if you aren't very careful in their use. I've personally managed to write an IRC bot that had a select loop that worked fine on i386 but didn't on amd64 until I figured out what was happening to the size of the structure behind it.
link
arghwhat 830 days ago
The kernel decided to have a different uAPI on different architectures. This is not just struct size that might differ, but the fields available and their possible values. Imagine a JSON field being a numeric constant in one arch, but a string in another. I get why they did it, but it certainly causes... surprises.

I imagine the issue you experienced might have been either that you hardcoded the numeric size instead of using sizeof and then building on a different architecture, or that you redeclared the struct for one architecture, ignoring that you were building for another architecture.

Not to undermine the annoyance or surprise-factor of your bug, I am tempted to say that it falls into generic logic bugs rather than the fault of any system. Changing to an encoded with dynamic length for example would just introduce different classes of logic bugs, like the whole series of possible issues within JSON parsing/serialization and requiring dynamic buffers.

A struct on the other hand only requires referencing the right struct declaration - the only amount of care you need is to include and use them. In my opinion, this is the maximum possible convenience for such system.

link
Cloudef 831 days ago
I was quite disappointed by the ABI differences between different architectures when I was doing network transparent uinput.

https://git.cloudef.pw/uinputd.git/tree/common/packet.h#n34 https://git.cloudef.pw/uinputd.git/tree/server/uinputd.c#n16

(Excuse to write code to use my PS Vita as gamepad :D)

link