yi zhang - Sun Microsystems - Beijing China wrote:
> Seems we can only poll NIC driver's interrupt ISR to receive ethernet
> packet from NIC,
>
> it seems that mac_rx() is just used to handle interrupted received packet.
>
> I need to manually write a polling function to replace this call back
> function.
>
> question is: can anyone give me some clue on where to find this ISR
> function and call it manually?
>
It doesn't uniformly exist. I think you should give up for now on this
effort. If you really want this feature, then you probably need to
invent a new GLDv3 API, and that requires ARC case work and more energy.
-- Garrett
> Thanks
>
> 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.
>>
>>
>>
>
> _______________________________________________
> networking-discuss mailing list
> [email protected]
>
_______________________________________________
networking-discuss mailing list
[email protected]
