Page 1 of 1

comprehensive kernel feature and design concepts.

Posted: Thu Jan 05, 2012 8:31 pm
by anadon
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.

Re: comprehensive kernel feature and design concepts.

Posted: Thu Jan 05, 2012 8:34 pm
by anadon
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.

Posted: Fri Jan 06, 2012 1:38 am
by bluemoon
anadon wrote:Also, I've been wondering why protocols can't be used on any interface. ie. TCP/IP over USB or Audio.
It's a complex issue. I try to list a few:
[*] 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.

Re: comprehensive kernel feature and design concepts.

Posted: Fri Jan 06, 2012 1:34 pm
by Brynet-Inc
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.

Posted: Sat Jan 07, 2012 10:11 pm
by anadon
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.

Re: comprehensive kernel feature and design concepts.

Posted: Tue Jan 10, 2012 6:09 am
by Combuster
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

Re: comprehensive kernel feature and design concepts.

Posted: Tue Jan 10, 2012 6:58 am
by Solar
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.
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.

Re: comprehensive kernel feature and design concepts.

Posted: Tue Jan 10, 2012 4:36 pm
by JackScott
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.

Posted: Wed Jan 11, 2012 12:43 am
by rdos
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).