1

I have read the general answers to these related questions,

but still left with questions of my own. For example, on int 0x80 the kernel services the system call, but what does it mean to "service" a call? e.g. if a service call is made for getuid

#define __NR_getuid (__NR_SYSCALL_BASE+ 24)

then once int 0x80 occurs, the kernel services the call. So what exactly must the kernel do to implement getuid? Somewhere there must be some code which runs after int 0x80. Assuming having downloaded the Linux kernel source, where (e.g. what path) might you find the source code implementation for __NR_getuid?

Community
  • 1
  • 1
T. Webster
  • 9,605
  • 6
  • 67
  • 94
  • 1
    You say you read [my answer](http://unix.stackexchange.com/a/804/138), but you apparently didn't get to the last paragraph, which points you to a book that answers all this. I know "read the book" is not a proper SE answer, but really, it's the right answer in this case. You're not going to learn how the kernel really works one Q&A answer at a time. – Warren Young Jan 24 '13 at 22:57
  • @WarrenYoung, I appreciate your attention to my question. I presume you've voted to close this. Could you at least point me to chapters of that book where I might find the answer to this question? I like your last sentence. Might the answer be found one chapter or one book at a time? – T. Webster Jan 24 '13 at 23:47
  • I voted to close it because it's not on topic here. Stack Overflow is for specific questions about *programming*. If you had asked how you change `getuid()` to behave differently, I doubt I'd have voted to close it, particularly if you'd said what you'd already tried. Questions on how to spelunk through a particular bit of code work better on sites where you find more people who know the code in question. In this case, I'd suggest [unix.SE](http://unix.stackexchange.com). But until a moderator bothers to move this question (assuming anyone does) I've expanded my comment into an answer below. – Warren Young Jan 25 '13 at 00:40

2 Answers2

3

The handler for getuid(2) is in kernel/timer.c, but you're going to find a single-line function there which won't enlighten you at all.

I found that file by saying make tags at the top level of the kernel source directory, then saying vi -t sys_getuid. sys_*() is how the syscall entry points are named in the kernel. Having done that, you can see why the find command given by 0xDen should work, and in fact does here on my system. But, using tags is faster and easier.

This is why I keep recommending that those who want to understand how the kernel works read a book on it. These books don't literally tell you how each and every syscall is implemented, since that would require that it basically walk you through all the code, line-by-line. There are millions of SLOC in the kernel. If you printed it out, it would literally require a bookcase to hold it all, even if you printed it in small text, double-sided.

Even if you ignore all the non-core parts, such as drivers, weird filesystems, less popular CPU types, etc., so that you were able to cut this down to 1% its total size, you'd still be left with a hundred thousand SLOC to plow through. That fills a big book all by itself, without leaving room for much commentary.

So, what a book on the kernel is going to do is give you the overall understanding of what goes on in there so that you will be able to find out where things live and how they are activated yourself. You will learn about the data structures that tie it all together, so you can follow the call chains, etc.

Warren Young
  • 40,875
  • 8
  • 85
  • 101
0

find -name "*.c"| xargs grep -n -E "SYSCALL_DEFINE" | grep getuid

0xDen
  • 86
  • 2