Jomathan wrote:
> So, if your non-invasive probe gives few false positives, I'd use it.
> Otherwise you lose the ISA IOports that your probe fals matches.  Only
> do the invasive (outboard reset) probe if it's absolutely necessary.

Right you are. There even aren't any io ports, just the shared memory area,
so no harm for a false positive probe on typical systems.

> There's no need to create a device node.  Even 4.2BSD-derived
> systems can handle downloading firmware to network-interface devices.
> Matt Thomas and I keep bouncing around ideas about how to do this in
> an MI way, but there's no solution in the tree yet..

I would be interested, when this makes it in. My driver is supposed to be
completeley machine-independend (there even is an S-Bus variant of the card).
 
> 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)

> If you can get hold of a specific interface name under /dev/isdn, then
> I'd suggest adding a socket-level ioctl that takes that interface
> name, and a pointer to the entire firmware image for your outboard
> device, and writes the code to the card and does the reset in one fell
> swoop. 

I'll have a look at that.


Thank you,


Martin