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.
After power on I'll have to download a tiny bootsrap into a part of the
2k shared space, togle some other bytes in this space and boom- reset does
the card and executes the code I wrote there. This code then probes some
details of the card (exact model, memory, ...) and writes the results to
some place in the shared area. My probe routine picks this up from there
and succeeds.

At attach time, basically the same happens again. This would be the right
place to do it first time, but I can't realy probe anything inside the card,
as it's visible only to the downloaded code.

Then the card is left in "waiting for download" state. The real code is
downloaded from userland (it's ISDN protocol specific, therefore user config
files must be read to determine which file to download). The card has no
device node, it just hooks into the upper ISDN layers, which have a common
/dev/isdn device. I could create a download channel through all upper layers
and issue an ioctl on /dev/isdn switching it into "download straight to card
x" mode and write the code to /dev/isdn, ending with another ioctl. Or I could
make the upper layer pass unknown ioctls down to the card and make a single
ioctl giving a file name (fs/inode) meaning "grab that file and put it on
the card". Another way would be to create a device node just for the purpose
of downloading protocol software to the card.

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?

And which way would you arrange the final protocol download?


Any suggestions welcome,


Martin