On Wed, 13 Dec 2017, Michael van Elst wrote:
You know that AmiTCP is based on Net/2 code ?
I do. It's right at the top of their README document. However it appears to be stagnant after 2012, and the devs seem to be offline. I also find it vulnerable to a couple easy hacks that cause guru meditations. However, I've considered that it might be easier to fork AmiTCP than to start over. The jury is still out.
AmigaOS actually only knows "kernel" threads, it doesn't know SMP. But there is no problem to just use the MP_SAFE stuff.
That makes sense. I'm still getting acquainted with AmigaOS. I have a lot to learn, it seems. However, as you point out, this is not a big deal.
As AmigaOS software interrupts are something very different from NetBSD softints, you have to replace them with threads.
Hmm, that sounds like "real work". Thread marshaling is more of a pain than softint_*(). I guess that's one reason why folks use it. It's a bit intimidating, though. Threads have always been painful in my experience, but it's probably just lack of use threads on my part.
AmigaOS doesn't distinguish between kernel and user, so "running in user space" has little meaning as the kernel runs "in user space" too.
Well, this I did realize, but I was speaking more about the items that NetBSD uses in kernel vs user space. I'm thinking primarily of the memory management kmem_*() stuff. I'm thinking a lot of that will just degenerate into standard memory allocation.
AmigaOS doesn't allow to allocate memory from interrupts, that's why all network stacks implement their own mbuf pools.
Well, my limited understanding is that it's not a great general practice to allocate memory in an interrupt handler anyhow. I was under the impression that you're better off building a free list and preallocating some buffers. So, that won't be too terrible, I guess.
You would create a BSD-like interface driver for the "SANA-II" device. Instead of pushing mbufs to bus_dma you would map this to the SANA-II facilities.
Ah, that makes more sense than what I was thinking. Thanks for that insight. I started by thinking I should adapt the stack code to the SANA-II struct style. What you are saying will be much better, I think.
You probably need an "interrupt thread" that handles input, this would also avoid issues with memory allocation.
Hmm, yes, I've seen similar techniques before with threads to replace other types of event handlers. I still dread the thread sync, but that's my own problem. :-)
One problem with the "interrupt thread" is additional overhead, something you will notice on the slower hardware.
Well, I'm working with newer Amiga hardware. In this case a system with an FPGA Apollo core. It's very fast. It's like a 300Mhz 68060 if there ever was such a thing. As the devs put more work into the core, it's just getting faster and faster. I hear an MMU is in the works, too, which makes me wonder about NetBSD running on this beast at some point. However, I know it's not a priority for the devs and they get hounded by Linuxites about that which annoys them. So, who knows. As you know AmigaOS doesn't use an MMU.
IPv6 (and to some degree IPSEC) is nowadays required all over the world and I even use an Amiga (running NetBSD) that utilizes both.
You are right, but not in too many home environments that I know. Even in big data center environments, it's still mostly optional (at least here in the USA). I'm not trying to gainsay you, but I'm making excuses to stay away from those bits as my ability with crypto doesn't extend far behind implementation and staff ciphers. If anything went wrong, I'd be at the mercy of the upstream code. I know excuses excuses....
Thank you kindly for the information and commentary, though. I appreciate it.
-Swift