Greg Earle wrote:
...
>You folks are talking about something that already exists.  It's called "DP",
>I've used it 24x7 for eons, and you can find out all about it via
>
>	ftp://phoenix.ACN.Purdue.EDU/pub/dp/*
>
>Once upon a time there was 386BSD code inside it, but given that it uses
>STREAMS I doubt that it would be easy to convert to NetBSD without a fight (-:

Humm.  Have to disagree on this one.  It's a sticky kernel-land/user-land
issue.

First off, I think all the serial line protocols need a wrapper like all
the ether drivers have (this is not my idea - I'm just repeating some
comments Chris made to me about 6 months ago - in reflection he was right)

1. All of the serial protocols, cisco hdlc, ppp & slip are "network packet
providers" just like an ethernet driver.  There needs to be a layer which
hides them below the if layer and encapulates all the common stuff. (I plan
to work on this, but who knows when)

2. this layer needs to be able to provide some notification to a userland
process and recieve some control info from a userland process.  Today this
looks (to me) like ioctl's.  It's interesting to note that BSDI put all of
PPP in the kernel.  I think netbsd should also.  I don't, however, think
that modem dialing or ISDN connection establishment should be in the kernel.
So, I'd claim there should be a psuedo device which would allow a user land
proc to get frame level access and signals.  He's my simple minded mental 
picture:

	existing if layer
	    ^
	    |
	+-----+-----+                 <-- protocol layer
	|     |     |
	PPP   SLIP  cisco HDLC
	|     |     |
	+-----+-----+--+              <-- framer layer
	  |            |
	 async        sync
	 hdlc framer  framer
	  |            |
	  async       sync
	  com dev     com dev

In this picture the framer layer would have a psuedo device which would allow
one to get raw frames from the transport, via a "tap", which would allow
a migration path for the current vintage pppd (which wants to read/write
frames in user space and get SIGIO when they appear)

the protocol layer would also have a psudeo device which would allow one to
get notification if a frame was being sent "down" from the kernel IP router
and the link was not up.  This interface should pass the entire IP packet
up to the user space proc so it can make a complex decision about bringing up
the link or dropping the packet.  blech.  I should go reread the screend
paper at this point ;-)

just my thoughts.  it would be nice if there were a framework which divorced
SLIP and PPP from their framer and the serial device which feeds the framer
(if any).  This way async, leased line sync and ISDN can all coexist.

have at it..
-brad