>I've got a design question I'd like you to comment on:

>I'm writing a device driver for an active ISDN card. This card has its
>own processor, own memory and maps 2k of it shared in the ISA bus space.
[...]


>Now my questions are: would you do the double probe/attach stuffe the
>way I outlined it or would you belive a far less restrictive probe verifying
>only the presence of the shared memory and some defined values which should
>be there after reset, leaving all download stuff to the attach routine?

hi Martin,

As you've noticed, you _have_ to dro a reset of the outboard processor
in the attach code. Other driver's probe routines may have clobbered
ether the card or the device attach args, between your driver's probe
routine and your driver's attach routine being called.  You cannot
assume otherwise, and so you have to do the outboard reset in the
attach.

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.

>And which way would you arrange the final protocol download?

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..

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?)

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.