>> If there's no abstraction for a single interface behind the ISDN
>> layer, I'd think that's a bug in the ISDN code.  (You _might_ end up
>> usnig multiple 2B+D hardware intefaces underneath /dev/isdn, yes?)

>The interface itself is nothing realy important outside of the isdn
>management itself. There are D and B channels, yes, and you get char devices
>assigned to B channels dynamicaly when you do speech or terminal emulation.
>Everything else stays inside the kernel (connecting B channels to ppp or ip
>doesn't need a device node)

Martin,

I don't agree, I think the underlying interface *is* important.  It
might be a PCMCIA card.  You might want to swap it. You might have two
or more of them.  (If nothing else, You might be talking to a private
X.25 switch in a lab)

Everything you say about devices being unimportant `outside of [isdn]
management' could apply equally well to IP/TCP. No? 

But the BSD networking stack *names* each underlying interface, and
lets you find the names, and issue ioctls against a specific name, so
you can configure them up, or down, or change their EPROM state, or
(on some systems) download new code into them, or reconfigure outboard
FPGAs, or whatever.

If the ISDN stack doesn't let you name specific interface devices and
let you do SIOC-style ioctls (or a new ISDN-specific set) against
specific hardware interfaces, then I think that's a bug in the ISDN
stack.  Does it really not let you do that?