According to a comment in one of my previous Questions Linux System Calls. Linux wasn't implemented on 8086/88 Intel CPUs. So what was the first Intel CPU to support Linux and implement its system calls?
From the horse's mouth itself (with no insult intended to Linus):
Hello everybody out there using minix -
I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones.
This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
I've currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I'll get something practical within a few months, and I'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-)
Linus (torvalds#kruuna.helsinki.fi)
PS. Yes – it's free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.
This is from the August '91 Usenet posting where Linus first announced his baby.
Hence 386 was the first CPU it was implemented on.
Only those of us who suffered having to lock memory sections at their location in Windows real mode, to prevent the memory manager emulator from moving them around without telling you, will appreciate what a good move Linus made in not trying to shoehorn Linux on to earlier CPUs.
I particularly love the:
just a hobby, won't be big and professional like gnu
comment. If only Linus had realised how big this beast would become.
Related
difference between Linux kernel and UNIX kernel(such as FreeBSD) from programmer's point of view.
I searched several articles about this. They compared these from User's view and Administrator's view also from Company's manager's view.
Can any body find article or say something from programmer's view?
The programmer I means, both user land programmer or kernel level programmer?
Any hints or enlightenment is really appreciate.
Wish this is not a cliche question make everybody sick. :P
From a standards point of view there really isn't any difference. Linux is a "POSIX" compliant OS, FreeBSD, Mac OS X and Solaris are also all "POSIX" compliant. In theory at least.
Once you move past the standards there are quite a few differences. Linux as inotify, udev and a bunch of other systems that are unique to it. FreeBSD has kqueue. There are differences in their exact implementations of things like ptrace. For example Mac OS X's ptrace has almost no functionality that you will find in the other Unix systems.
Beyond custom libraries there are differences in development tools. Solaris and FreeBSD have dtrace. Linux has valgrind. Mac OSX has instruments.
What level you are looking at will affect what differences you see or don't see.
For a userland programmer, there is no difference. The userland programming will be coding to a language VM like C and it will be up to the C library routines to translate that into lower level system calls.
Those using other tools such as Perl, Python, Java and so on, are even more removed from the kernel so it will not directly affect them either.
In terms of the kernel programmer, the differences are likely to be significant since the kernels themselves are different. I haven't seen the FreeBSD internals although I've done a fair bit of work inside Linux, so I can't comment intelligently on the low-level differences but (and this final bit is informed opinion, not gospel), since they run independent development streams, the chances of having exactly the same view is small.
I would like to learn about linux/Unix kernel programming for scalable multi processors (smps). I found this book UNIX(R) Systems for Modern Architectures http://www.amazon.com/UNIX-Systems-Modern-Architectures-Multiprocessing/dp/0201633388/ref=pd_rhf_p_t_3 . Is there any other good resources or a better book since its released in 1994. Thank you very much in advance.
Thanks & Regards,
Mousey.
Definitely buy this excellent book! You will get thorough introduction into:
caches, their types, and how to deal with them in the kernel,
synchronization and what hardware primitives are behind it,
general kernel designs as related to concurrency (cli/sti, giant lock, cli+spinlock, etc.)
The book is general enough not to be out of date by now. The only thing I don't remember mentioned there is NUMA, but I don't think there are any good published texts on this subjects yet except for maybe Gorman's Linux memman paper (somebody correct me if I'm wrong here).
I think the book was really worth the money.
Understanding the Linux Kernel is a great book about how the Linux kernel is built, it describes Linux 2.2, 2.4 and 2.6 (Third Edition).
If you want to make drivers, there's Linux Device Drivers , and is also a reference about how Linux is built.
For Linux, Rusty's Unreliable Guide to Kernel Locking is a must-read. After that, you can also read the file Documentation/spinlocks.txt located in the Linux kernel sources.
I'm preparing myself to build RTOS solution on top of Linux this going to work on embedded device. I've done some investigation by myself but still I'm a bit confused.
Those are my criteria:
Easy to run on Samsung s3c2440 ARM9 machine
Open Source
Works together with Linux
Good community support
I've seen RTLinux and Xenomai. Xenomai looks more like thing for me, but still I'm confused.
Any good advice, pro's and cons?
I have not done any work with Real Time systems, but I know if this and this. I hope it helps or that it can at least put you in the right track.
The question is do you really need hard RTOS?
You may be able to get away with something like uClinux http://www.uclinux.org/
Check out montavista if you need commercial support.
If you have decided on a processor, I suggest you find a development board or kit and use the recommended operating environment. Including development tools and OS.
With the aid of FCSE enabled by Xenomai, Linux with the real-time extension can work pretty weel on ARM9 based boards like S3C2440.
This presentation covers some concepts: http://www.slideshare.net/jserv/realtime-linux
If you need free and absolutely stable out of the box with the lowest latencies, consider something like RTEMS (not Linux based, but does provide POSIX functions).
If you can afford it and want something absolutely stable out of the box with very low latencies and have a general purpose OS with all the bells and whistles, check out QNX - its got the same GNU userland/toolchains you're used to and is POSIX compliant.
RTLinux is best avoided - very buggy. Xenomai/RTAI can have decent success, although it has more limitations than QNX. Everything else is going to bleed you for large sums of money so you might as well choose the best option :-).
Yeah I know ... Some people are sometimes hard to convince of what sounds natural to the rest of us, an I need your help right now SO community (or I'll go postal soon ..)
One of my co-worker is convinced the linux kernel code is not re-entrant as he reads it somewhere last time he get insterested in it, likely 7 years ago. Probably its reading was right at that time, remember that multi core architecture was not much widespread some time ago and linux project at its begining or so was not totally well writen and fully fledged with all fancy features.
Today is different. It's obvious that calling the same system call from different processes running in parallel on the same architecture won't lead to undefined behavior. Linux kernel is widespread now, and known for its reability even though running on multicore architectures.
That is my argument for now. But what would be yours to prove that objectively ?
I was thinking to show him off some function in the linux kernel (on lxr website ) as the mutex_lock() system call. Eveything is tuned to get it work in concurrent environnement. But the code could be not that obvious for newbie (as I am).
Please help me.. ;-)
Search the kernel mailing list archive for "BKL". That stands for "Big Kernel Lock", which is what used to be used to prevent problems. A lot of work has been put into breaking it up into pieces, to allow reentry as long different parts of the kernel are used by different processes. Most recent mentions of "BKL" (at least that I've noticed) have basically referred to somebody trying to make his own life easy by locking more than somebody else approved of, at which point they frequently say something about "returning to the days of the BKL", or something on that order.
The easiest way to prove that multiple CPUs can execute in the kernel simultaneously would be to write a program that does a lot of work in-kernel (for example, looks up long pathnames in a tight loop), then run two copies of it at the same time on a dual-core machine and show that the "system" percentage in top goes above 50%.
At the risk of being snarky: why not just read the code? If neither of you are expert enough to follow the code through an interrupt handler and into some subsystem or another where you can read out the synchronization code, then ... why bother? Isn't this just a dancing on the head of a pin argument? It's like a creationist demanding "proof" of evolution when they aren't interested in learning any biology.
Maybe you should have your friend prove Linux is not reentrant. Burden should not be on you to prove this.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'd like to gain better knowledge of operating system internals. Process management, memory management, and stuff like that.
I was thinking of learning by getting to know either linux or BSD kernel.
Which one kernel is better for learning purposes?
What's the best place to start?
Can you recommend any good books?
In college, I had an operating systems class where we used a book by Tanenbaum. In the class, we implemented a device driver in the Minix operating system. It was a lot of fun, and we learned a lot.
One thing to note though, if you pick Minix, it is designed for learning. It is a microkernel, while Linux and BSD are a monolithic kernel, so what you learn may not be 100% translatable to be able to work with Linux or BSD, but you can still gain a lot out of it, without having to process quite as much information.
As a side note, if you've read Just for Fun, Linus actually was playing with Minix before he wrote Linux, but it just wasn't enough for his purposes.
As a Linux user I'd say Linux has a great community for people to learn about the kernel. http://kernelnewbies.org is a great place to start asking questions and learning about how the kernel works. I can't make a book reccomendation, but once you've read the starting material on kernelnewbies the source is very well documented.
Aside from the good books already mentioned (Opeating System Design & Implementation is particularly good), get a hold of a 1.x release Linux Kernel, load it into VMWare or VirtualBox and start playing around from there.
You will need to spend a lot of time browsing source code. For this, check out http://lxr.linux.no/ which is a browsable linked version of the source and makes life a lot easier. For the very first version of Linux (0.01) check out http://lxr.linux.no/linux-old+v0.01/. The fun begins at http://lxr.linux.no/linux-old+v0.01/boot/boot.s. As you progress from version to version, check out the ChangeLog and dig into those parts that have changed to save you re-reading the whole thing again.
Once you've gotten a hold of the concepts, look at 2.0, then 2.2, etc. Be prepared to sink A LOT of time into the process.
Linux
Device Drivers
Linux Core Kernel Commentary
Operating Systems Design and Implementation
I had previously bought these books on recommendation for the same purpose but I never got to studying them myself so only take them as second-hand advice.
I recommend you the BSD kernels! BSD kernels have far fewer hackers so following their evolution is easier. Either BSD and Linux kernels have great hackers, but some people argue that BSD lower fame filters out novice ones. Also taking design decisions is easier when the sources are not being updated 100 times a day.
Among the BSD choices, my favorite one is NetBSD. It might not be the pain-free choice you want for your desktop, but because it has a strong focus on portability, the quality is quite good. I think this part say it all:
Some systems seem to have the philosophy of “If it works, it's right”. In that light NetBSD's philosophy could be described as “It doesn't work unless it's right”
If you have been working long enough, you will know that NetBSD is a quite joy for learning good coding. Although professionally you will find more chances with Linux
Whichever choice you take, start joining their mail lists, follow the discussions. Study some patches and finally try to do your own bug-fixing. Regarding books, search for Diomidis Spinellis articles and his book. It is not exactly a kernel book, but has NetBSD examples and helps a lot to tackle large software.
Noting the lack of BSDs here, I figured I'd chip in:
The Design and Implementation of the FreeBSD Operating System (dead-tree book)
Unix and BSD Courses (courses and videos)
FreeBSD Architecture Handbook (online book)
I haven't taken any of the courses myself, but I've heard Marshall Kirk McKusick speak on other occasions, and he is really good at what he does.
And of course the BSD man pages, which are an excellent resource as they are maintained to a far greater extent than your average Linux man-page. Take for instance the uvm(9) man-page, describing the virtual memory interface in OpenBSD.
Not quite related, but I'll also recommend the video History of the Berkeley Software Distributions as it gives a nice introduction to the BSD parts of the UNIX history and culture as well as plenty of hilarious anectodes from back when.
There's no substitute for diving into the code. Try to find a driver or subsystem that you're interested in and poke around with it. With tools like VMware Workstation it's super easy to make whatever changes you want, snapshot the VM, and run your modified kernel. If the kernel panics on boot, who cares? Just jump back to the snapshot and fix the problem.
For books, I strongly recommend Linux Kernel Development by Robert Love. It's a wonderfully written book -- lots of information, organized sanely, and humorous... not dry reading at all.
Take Mike Stone's advice and start with Minix. That's what Linus did! The textbook is really well written, and Tannenbaum does a great job of showing how the various features are implemented in a real system.
Nobody seems to have mentioned that code-wise BSD is much cleaner and more consistent. The documentation's way better too (as already mentioned). But since there's a whole lot of fiddling with whatever system you choose - I'd pick the one you use more often.
Linux and Minix are fun to learn. If you also want to learn how a modern micro-kernel operating system looks like, you can look at QNX. The complete documentation is available online and it is very accessible. For example, this online book.
When I was at uni I spent a semester studying operating systems, and as part of this had an assignment where we had to implement a RAM-based filesystem in Linux.
It was a fantastic way to get to understand the internals of the Linux keurnel and to get a grasp on how everything fits together - And a heck of a lot of fun playing around with how it interacts with standard tools too.
I haven't tried it myself, but you can go to Linux From Scratch and start building your own Linux distribution. Sounds like something that'll take a junkload of time, but will result in an intimate knowledge of the guts of the Linux kernel and how each part works. Of course, you can supplement this learning by following any of the other tips here.