Re: [hatari-devel] Network support for Hatari

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Thanks for working on this!

On 10.5.2021 14.24, Thorsten Otto wrote:
> Some other notes:
>
> - the harddisk image contains a freshly compiled mint kernel, with changes
> that are already pushed to the repo, but (due to bintray closing) are not yet
> downloadable as snapshots.

Good to have a test setup!


> - In aranym, 2 small helper tools are used for certain configurations
> (aratapif and bpf_helper), which are not part of the patch. However that are
> independent programs, and i don't expect much problems to integrate them, but
> i'm just not very used to cmake to do that cleanly.
>
> - ARAnyM uses AutoVector Interrupt #3 for the reception thread, and calls
> TriggerInt3() for this purpose. In Hatari, i translated that to a call to
> M68000_Exception(), i hope this is the right thing to do

You're doing that both for #3/SCC + #5/VME in hatari-glue.c::intlev() & 
newcpu.c::iack_cycle().

I'm wondering why SCC case wasn't already in use
as we have some SCC support already.

Nicolas/Thomas?


> (but seems to work,
> as seen in https://www.atari-forum.com/viewtopic.php?p=416923#p416923 )

You also mentioned there working on non-MiNT STing
driver for NF Ethernet, which sounded very
interesting (as then GEMDOS HD would also be
usable, unlike with latest MiNT).


> - no attempt is currently made to save/restore the state from snapshots, since
> i have no idea how to do that since open file descriptos are involved

I guess about only thing that could be done at
restore would be to close the socket.


> - There seems to be a leak on the thread, which is not killed when resetting
> the emulator (this is also present in aranym). Looks like there is no
> SDL_KillThread() function in SDL2 anymore?

Yes, SDL2 thread support sucks: https://hatari.tuxfamily.org/doc/bugs.txt

As you already have OS specific implementations
for ethernet handling, one option would be to use
OS specific threading primitives directly.

(Me being then able to use those to fix RS-232
threading for Mac would be a bonus. :-))


> - I have only tested it on linux so far, but verified that the sources for
> win32/macos compile at least
>
> - i also tried to avoid some of the c++isms (like declaration-after-
> statement), but it is possible that i missed some (activating the warning did
> not work, because that spits out also lots of warnings from header files).
>
> - the ethernet_darwin.c is an older implementation, which imho isn't used
> anymore (ARAnyM also unconditionally defines ENABLE_BPF for macOS, which
> causes the newer implementation to be used).

Similarly to Nicolas, I think it would be better
if these files were in their own directory.


Hatari function naming convention is that at least
non-static ones use a prefix that matches the file
name, but e.g. Darwin & Linux ones use "TunTap" prefix?


Looking at ethernet.h, only single EthernetHandler
implementation can be compiled in at the same
time, so ETHERNET_HANDLER_CLASSNAME, different
names for the implementations in OS specific
files, and separate headers for those are all
redundant.

Couldn't you just declare struct name in
ethernet.h and use that name in all the OS
implementations?


Tracing output is very inconsistent, see:
  grep LOG_TRACE ethernet.patch | cut -d'"' -f2

Please use common prefix for *all* NF_ENTERNET
trace logs (e.g. "ETH:" or "Ethernet:"), so that
users can grep & search them among other trace
output.


I would also like this huge patch to be split
up to few smaller commits, but I don't have
yet any concrete suggestion on how it should
be split.


	- Eero