I wrote:
> >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...

And Jonathan said:
> Yes. What I don't understand is, why anyone would do anything *else* :).
[..]
> 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.

No, not realy. That's why Paul separated if_ppp.c from ppp_tty.c.
Currently BISDN has no working tty support, but does ppp quite well.

I don't think the choice is that obvious: it's a one size doesn't fit
all kind of think (in german an "eierlegende Wollmilchsau"), as a user
you don't realy do anything with the device, your abstraction will be
the ISDN connection - coming in different shapes: network connection via
HDLC or PPP, character device in tty emulation, aplication specific when
doing speech or video or whatever special service you use. But as you
explained before, you do care about the card for things like downloading
code to it, hot-swapping it, ... 

Does the upcoming pcmcia code require something special for card to be
swappable? Does it need to have a character device attached?

Another way to integrate ISDN into the kernel would be the ISDN-bus: you
have an ISDN-controller attaching one ISDN-bus (as an abstraction for your
basic rate interface) and different devices attached to that bus modeling
the available services: a networking device, a tty device, a sound device
and others. You open a device and get a connection via that service or,
in the networking case, you ifconfig the device up and get a connection (or
a possible connection, as you would probably do dial-on-demand)

But would autoconfig allow you to attach one bus to multiple bus-controllers
(if you have multiple ISDN cards but only one BRI)?

I think I like this version even more then AF_ISDN.


Martin