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.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
