I've been thinking a while about features in kernel design and readining up on it when I can. I know the contemporary basics, such as symetrical and asynetircal multi-processing, dynamically loaded driver kernel modules. I've read up on old stuff, like monolithic kernel vs. nano-kernel vs. mach kernel. I've also come across some cutting edge abilities, such as sub-kernels. I'm interested in what other concept relating to kernels can be thought of.
I know I have not come across all the kernel features and concepts, and read plenty to try and catch up. I am hoping to get a list of features which relate to designing, creating, and the working of a kernel.
4 categories:
technologies in building
well established features
features which are newer/still in development
future concepts still being worked out
I'm hoping to find out what each involves, benefits and costs, dificulty to make, and so on.
comprehensive kernel feature and design concepts.
Re: comprehensive kernel feature and design concepts.
Also, I've been wondering why protocols can't be used on any interface. ie. TCP/IP over USB or Audio.
Re: comprehensive kernel feature and design concepts.
It's a complex issue. I try to list a few:anadon wrote:Also, I've been wondering why protocols can't be used on any interface. ie. TCP/IP over USB or Audio.
[*] Cost. Circuits involved, patents, etc
[*] Implementation complexity. TCP/IP would require a stack on both end
[*] Efficiency.
[*] And the most important part, most manufacturer trends to introduce their own standards in order to lead the industry.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Re: comprehensive kernel feature and design concepts.
TCP/IP over an audio device is also possible, it's used by ham radio enthusiasts for packet radio.
Re: comprehensive kernel feature and design concepts.
But I've been questioning why that isn't done dynamically--applying any protocol over any interface.
Anyways, this to look up so far: "usbnet linux" and "ham radio TCP/IP"
Where is some good documentation on the TCP/IP protocol? I keep getting whelmed by the sheer mass...it's less than elegant in my opinion.
Anyways, this to look up so far: "usbnet linux" and "ham radio TCP/IP"
Where is some good documentation on the TCP/IP protocol? I keep getting whelmed by the sheer mass...it's less than elegant in my opinion.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: comprehensive kernel feature and design concepts.
There's a ton of technical stuff out there, but if you lack fundamental knowledge or any technical reading skill then
a) you should not be here because we expect that from you.
b) get a good book: http://www.amazon.com/Computer-Networki ... 0132856204
a) you should not be here because we expect that from you.
b) get a good book: http://www.amazon.com/Computer-Networki ... 0132856204
Re: comprehensive kernel feature and design concepts.
Even setting aside the subject whether it's elegant or not, it's one of those things that has seen so widespread acceptance and use that it won't change anymore.anadon wrote:Where is some good documentation on the TCP/IP protocol? I keep getting whelmed by the sheer mass...it's less than elegant in my opinion.
Every good solution is obvious once you've found it.
Re: comprehensive kernel feature and design concepts.
All of TCP, IP and UDP are really quite simple protocols. Berkus is absolutely right, the IETF RFCs should have what you need to write an implementation from scratch (that's what they're designed for).
Re: comprehensive kernel feature and design concepts.
While IP and UDP are simply protocols, with good documentation that are relatively simple to code, I would't say the same about TCP. In order to code an effective TCP implementation reading the RFC is not enough. For instance, the trick to achieve good performance with TCP is to send-out multiple packets without waiting for acknowledgement. This is especially important over wireless connections with long turn-around times. Also, the PSH flag described in the RFC does not seem to be implemented in typical "socket" libraries (I do implement it though). I don't know why, actually, since PSH would imply you send-out the buffer immediately. Instead, I see settings that imply that timeouts are used to decide when to send. Another oddity that isn't described is that some implementations (at least Windows) doesn't think the socket is established until some real data (or an empty packet) is sent. This is not described in the RFC either (or maybe it is Microsoft-interpretation of the spec).