James Carlson wrote:
> Garrett D'Amore writes:
>
>> yi zhang - Sun Microsystems - Beijing China wrote:
>>
>>> So is there any other way worth trying? such as direct call NIC card
>>> driver without multi-thread?
>>>
>> Its not just multi-threading, but interrupts (or lack thereof) that you
>> have to be concerned with. If you can identify the ISR handler for the
>> NIC, you could directly call that, but its kind of a crap shoot.
>>
>> Again, I think the answer is, if you want a crash dump, use local disk.
>> Dumping over the network is likely to be risky, or just non-functional,
>> in a large percentage of cases where you're crash dumping. (Understand
>> also, a healthy bug free system should never crash.)
>>
>
> 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.)
> 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.)
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
