Subject: Re: Downloading code to IO processor
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Martin Husemann <firstname.lastname@example.org>
Date: 06/17/1997 10:01:00
> 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
I'll have a look at that.