Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!snorkelwacker!spdcc!ima!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: desperately need an answer
Message-ID: <403@minya.UUCP>
Date: 12 Jun 90 02:44:48 GMT
References: <9006061544.AA08499@ucbvax.Berkeley.EDU>
Lines: 35

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.