I'd not like the feature of callback NIC's ISR manually. because different NIC card had different NIC card drivers and its specified parameters to drive. If I would dump kernel memory core to network storage, I would write different dumping function to each specified NIC card. That's not what I want.
I am wondering did the NFS dumping feature still works or not on the latest Solaris10 and NV? James Carlson wrote: > Garrett D'Amore writes: > >> James Carlson wrote: >> >>> If we really want a network dump feature (diskless systems?), I think >>> we ought to take a page from the embedded system book: write a tiny >>> TFTP implementation. There's not much to it (you just need UDP and IP >>> headers) and you can poll the driver in a loop. It's simple and safe. >>> >>> >> Yes, that would work.... *if* you can figure out how to poll the >> driver. For modern NIC drivers, this may not be terribly obvious. >> (Ancient GLDv2 drivers register their ISR with the framework. *Some* >> GLDv3 may register a "poll" routine to allow the framework to poll >> without waiting for a hardware interrupts. But the vast majority of >> drivers do neither of these.) >> > > An explicit poll entry point (as is done with serial drivers for > exactly the same purpose -- dealing with I/O for kernel debug) is what > I had in mind here. > > The driver support issue is just that; we'd have to add this to the > list of required features for new drivers, and then go back and update > the old ones. Just as with Brussels or any other new thing we might > care to do here. > > >>> For what it's worth, the embedded systems I've worked on in the past >>> place both initial boot and dump logic into the system ROM, so that >>> there's no way it can be corrupted, and so that it's guaranteed to be >>> available -- unlike RAM. If we're talking about this feature in order >>> to support embedded systems, I'd suggest trying something like that. >>> >>> >> Same experience for boot. I've not run into any systems with dump >> support in firmware, although most of the embedded systems I've worked >> with have such tight memory constraints on their ROMs that it would be >> hard to fit anything else in ROM. (Think Sun Rays, certain tiny WiFi >> access point hardware, and -surprisingly- the E10K control board.) >> > > The TI34010 X11 terminal I worked on at DG had 32KB of EPROM, and > supported boot and dump via TFTP and (oddly enough) anonymous ftp. > The 80376[1] Annex terminal servers that I worked on at Xylogics had > TFTP, MOP, BFS, IPX, and some other more obscure load/dump mechanisms, > and did it comfortably in 64K. The MPC860T embedded systems at > IronBridge had (if I recall correctly) either 512KB or 1MB (depending > on configuration), into which was included a complete FreeBSD-based > stack, network management system, shell, VM-based hardware emulator, > and other components. > > I agree that some folks can't seem to scrape together decent > networking support even when given "lots" of space by embedded > standards. That doesn't mean that it's impossible or even very hard > to do. > > 1. Yes; 803*7*6 is accurate. It's an obscure part that was once > somewhat popular for higher-end embedded systems. > >
