> >Another point that comes to mind here: it has been proposed to treat
> >ISDN just as another link level network interface, create a socket address
> >variant carying ISDN phone no's and use the full socket interface as the
> >API of choice. This would fit nicely here...
> 
> Yes. What I don't understand is, why anyone would do anything *else* :).

I started/fuelded a discussion on this a while back (talking about
"block character devices" for hdlc), and have one reason (which I'd
be happy to be explained out of):

How do you add the idea of line disciplines to an interface?

Network interfaces, as I understand them, implicitly assume that there
is only one way of speaking on the net. Different protocols of course,
but one way of figuring out what a packet's doing. For Ethernet
interfaces, it's if_ethersubr.c. For token rings, it'd be something
like if_tokensubr.c. For a LocalTalk card (one of the ISA ones which
have on-board cpu's), it'd be if_ltalk.c. In each case, when a packet
comes in, there's one way to figure what to do.

With a z8530 SCC in hdlc mode, there's more ambiguity. You could be
doing ppp, or LocalTalk, or other stuff I don't know about. Thus the
driver needs some way of routing the packet to the right interface
code.

Rather than make one HUGE driver, my thought was that you'd open &
configure the device (either as a character device in /dev or a
network interface), then latch a pseudo-device on top. So if the
port is doing ppp, ppp0 would get fired up as normal. If the
port is being a LocalTalk node, an ltalk interface will start up.
But I think it'd be kinda confusing to see two interfaces in
ifconfig to run the same port. Plus, how does the zhdlc network
interface say what it's doing?

I'm asking this as I'd very much like to do something compatable with
what the isdn boards do.

> as there a conflict between ISDN, and the ppp code requiring that the
> lower-level device implement the tty software interface?  That would
> explain a lot.

I'm interested too...

Take care,

Bill