mo@messy.bellcore.com (Michael O'Dell) (06/06/90)
(1) the limitations aren't that severe because it turns out implementing TCP/IP isn't as piggish as first thought. Further, previous experience with putting NCP outside the kernel for just the suggestes reasons was a cosmic lose in terms of complexity. but the important one is.... (2) SPEED!!!!! The last thing in the world you want is a few extra context switches per packet and per network read/write. Putting it ouside the kernel almost guarantees extra data copies as well as the extra context switches. So, aside from being gratuitously complex and hideously slow, the idea is great. -Mike
CHAIBP@NUSDISCS.BITNET (06/07/90)
Clark, in his RFC 817, said that kernel implementation of TCP/IP would subject to many system limitations and suggested that only part of TCP/IP should be placed in the kernel, leaving the rest in the user processes. Now, what I don't understand is that why everybody still put the entire TCP/IP in the kernel - AT&T system V, Sun BSD Unix and many others all does just that. Does that mean that those limitations are never faced by them or that they have actually took his advice but provided the interfaces to the user processes in a way that gives them the illusion of interfacing with the kernel ? Desperately need an answer on that ! Please give me an answer if you do have one. Chai
jc@minya.UUCP (John Chambers) (06/12/90)
In article <9006061544.AA08499@ucbvax.Berkeley.EDU>, CHAIBP@NUSDISCS.BITNET writes: > Clark, in his RFC 817, said that kernel implementation > of TCP/IP would subject to many system limitations and > suggested that only part of TCP/IP should be placed in > the kernel, leaving the rest in the user processes. > > Now, what I don't understand is that why everybody still > put the entire TCP/IP in the kernel - AT&T system V, > Sun BSD Unix and many others all does just that. Does > that mean that those limitations are never faced by them > or that they have actually took his advice but provided the > interfaces to the user processes in a way that gives > them the illusion of interfacing with the kernel ? This one's easy. People are paid more for kernel work than they are for application-level work, so they have a strong incentive to do as much work there as possible. I've seen a lot of this, and it goes a long way to explain why Unix kernels are becoming so bloated. When you reward people better for using method A than for methods B, C, ..., it should come as no surprise that they will tend to use method A. Until a few years ago, I foolishly took the approach of doing work wherever it seemed best, and this was almost never inside the kernel. After a while, I noticed that the main effect of this was to make it clear to prospective employers that I was a kernel lightweight. Now I know better. (Note the lack of :-)s above. ;-) -- Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers) Home: 1-617-484-6393 Work: 1-508-952-3274 Cute-Saying: It's never to late to have a happy childhood.