Linked by Thom Holwerda on Fri 23rd Mar 2007 17:39 UTC, submitted by IdaAshley
Linux "Linux system calls - we use them every day. But do you know how a system call is performed from user-space to the kernel? Explore the Linux system call interface, learn how to add new system calls (and alternatives for doing so), and discover utilities related to the SCI."
Thread beginning with comment 224392
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Docs
by butters on Sun 25th Mar 2007 01:59 UTC in reply to "Docs"
Member since:

1) Completely true. There's some very helpful nuggets of wisdom in the Documentation directory, but many of these files are out-of-date, and large portions of the kernel simply aren't documented in plain English. However, the syscall interface and the key in-kernel APIs are well-documented.

The Linux philosophy is that the source code is the best documentation, and the high standards for coding style reflect this idea. I've hacked on a few UNIX kernels, free and proprietary, and the Linux kernel source is by far the cleanest and most deliberate kernel code that I've seen. The maintainers understand that simple code often outperforms sophisticated code, a lesson that my current employer has yet to learn...

Some outsiders complain that the code reviewers on LKML nitpick stylistic issues more than anything else. They do this for a reason. Code reviews can catch bugs, but they don't catch them all. A good code reviewer might find one out of every three bugs over a long period of time. Patch submissions will be broken from time to time, and often they will break other things.

The important things is that we are able to find and fix bugs when encountered. When the maintainers commit patches to the mainline, they aren't guaranteeing that the code is flawless, but they are guaranteeing that the code quality is high enough that the community can maintain it even if the original developer gets hit by a bus. That's why the Linux kernel maintainers are sticklers for style. They would rather have well-written code with some bugs than flawless code that nobody really understands.

2) Linux will probably never have a stable in-kernel API. Not now, not at some point in the 2.6.x series, and probably not in any later series. Linux is developed in the open, completely transparent to anyone who wishes to support it. They don't want to freeze the in-kernel APIs, limiting our ability to innovate and improve, just so that proprietary vendors don't have to monitor the LKML from time to time. If any vendor is unsure of how a planned API change will affect their driver, the kernel community will be glad to discuss the changes and recommend solutions. For example, the kernel community prepared extensive tutorials and documentation when the workqueue API was introduced in the 2.6.x kernel.

Having very stable APIs actually makes change more disruptive. Look at how many devices and applications don't function correctly on Vista. How could it be that Creative (for example) was caught off-guard by an OS release that was 2 years late? Were they expecting to grab a copy of Vista RTM, boot up, and have their audio drivers magically work with the new driver APIs? Many hardware vendors are just grossly negligent. There's no way to develop an OS that keeps their drivers working without staying stuck in the Dark Ages, so we don't make any attempt to do this in Linux. If you give us the code, we'll make sure it stays up-to-date. If you refuse, then the best we can offer is complete transparency and an open forum for communication.

Haven't found one that exists, so the only search I have of use right now is google.

I recommend cscope, ctags, or, if you're feeling ambitious, OpenGrok. Use google to find them ;-)

Reply Parent Score: 3