Anatomy of a system call, part 1 [LWN.net]

Anatomy of a system call, part 1

Posted Jul 11, 2014 9:01 UTC (Fri) by geuder (subscriber, #62854)
Parent article: Anatomy of a system call, part 1

Thank you for the very detailed description. Occasionnally I had to track down (parts of) this from the source for debugging some issue and it can be very tedious.

A little detail, but a nuisance for humans, especially if you debug an emebedded target and compare to your desktop known to work correctly: What is the technical reason to have partially architecture specific syscall number? Passing a number in a register does not look like anything inherently architecture specific.

If you quickly need to see the syscall numbers for a given architecture I have seen the hint to look at strace source. I'm just at my phone now, so I don't compare the source now, but I vaguely remember it was indeed easier to navigate than the kernel source proper. Was it so that strace distributes ready lists while for the kernel they need to be built for each architecture?

to post comments

Anatomy of a system call, part 1

Posted Jul 11, 2014 9:53 UTC (Fri) by sasha (guest, #16070) [Link] (3 responses)

> What is the technical reason to have partially architecture specific syscall number?

For "compatibility" with other, older OSes used on the architecture. No, I do not understand what kind of "compatibility" you can get in such a way, but it is the main reason.

Anatomy of a system call, part 1

Posted Jul 11, 2014 16:55 UTC (Fri) by alonz (subscriber, #815) [Link] (2 responses)

I believe by now the reason is mainly historical.

Originally (in the days of Linux 1.x / 2.0) Linux attempted to be binary compatible to existing Unices on common hardware (the personality(2) system call is also part of this). As time passed, compatibility with other Unices became mostly a non-issue – but now we do need to maintain binary compatibility with older Linux binaries…

Anatomy of a system call, part 1

Posted Jul 11, 2014 22:12 UTC (Fri) by geuder (subscriber, #62854) [Link] (1 responses)

> Originally (in the days of Linux 1.x / 2.0) Linux attempted to be binary compatible to existing Unices on common hardware

That sounds like a reasonable explanation. Besides that back in those days what Unices were running on x86_64 and ARM? And these 2 differ. Yeah well, maybe the dependencies are not direct, but somehow indirect over other platforms?

Anatomy of a system call, part 1

Posted Jul 11, 2014 22:22 UTC (Fri) by sfeam (subscriber, #2841) [Link]

As I recall, linux binaries for alpha would run under Digital Unix on alpha.