Date: Wed, 10 Jan 1996 18:11:36 -0700 From: Nate Williams <nate@sri.MT.net> To: dennis@etinc.com (dennis) Cc: hackers@freebsd.org Subject: Re: pppd vs ijppp Message-ID: <199601110111.SAA19830@rocky.sri.MT.net> In-Reply-To: <199601110013.TAA00308@etinc.com> References: <199601110013.TAA00308@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >A kernel is something that needs to be as simple, small and efficient/reliable
> >as possible, that's why it generally contains only :
> >
> > 1) stuff that *can't* be elsewhere because of the architecture of
> > the system.
> > 2) stuff that would not be efficient enough in user space.
> >
> >PPP basically needs to (A) emit/receive network (IP or other) packets
> >and (B) encode/decode them. (A) *needs* to be in the kernel. (B) doesn't,
> >except for performance (when SLIP was first implemented, CPU resources
> >were scarce enough that this made a big difference even on personal
> >workstations. Not anymore).
>
> Bravo...you've trivialized datacomm to a point of utter
> stupidity.
Not really, he's just explained the difference between user level code
and kernel level code. If that makes you feel bad, tough. :)
> What you've missed is that stability and performance are
> the key issues
Hence the reason for user-level code. Stability is *greatly* enhanced
with the user-level code because it can be debugged separated from the
rest of the kernel. You only to worry about the PPP specific functions,
rather than worrying about VM/kernel locking issues, etc..
> and event managment is severely degraded when you
^^^^^^^^
Define severely? The system is beat up much more by an emacs user than
by someone running user-land PPP, so does that mean we should bring in
emacs into the kernel?
> separate the functionality from the kernel. (This, perhaps, is why the
> pppij is so damn unreliable *light bulb*)
Or maybe it's got a bug in the event handling code? Naw, that would
make too much sense. It's obviously a performance bug, so will just
take this bug-free code and import it directly into the kernel.
> A good example is the routing function, which is in the kernel because
> its too damn inefficient in user space. Mr kendals example of "lets
> move tcp out of the kernel" was a good analogy to the kind of
> arguments we're getting on this thread.
You've got an axe to grind, and because you happen to write PPP drivers
you're bent on proving that what you are doing is correct. Well, in
this case it isn't a 'right/wrong' decision. Both approaches have
merits, and both approaches exist.
Your approach leads to 'put everything in the kernel', which goes
against the 'original' unix way of thinking that 'simpler is better'.
Only put the functionality in the kernel which is *absolutely*
necessary. If decent performance could be gotten by moving the routing
code out of the kernel I'd be all for it. I'd have a much better chance
of debugging the stupid ARP bug I'm seeing if I could do it in
user-land, and I'm sure the code would be easier to read.
Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601110111.SAA19830>