Elks networking

Elks networking

[Derek Johansen]

Do sockets/networking work in elks and if so to what extent and in
what environment.  In my environment of elks on qemu on Ubuntu on Vbox
on win8.1 when I try to run telnet I get a system crash.

But that is a lot of layers and opportunities for failure.  If I pared
it down to say elks on qemu on w8.1, or elks on vbox on w8.1, would
networking work at all?

Re: Elks networking

[Jody Bruchon]

On 2016-05-28 16:17, Derek Johansen wrote:
> Do sockets/networking work in elks and if so to what extent and in
> what environment.  In my environment of elks on qemu on Ubuntu on Vbox
> on win8.1 when I try to run telnet I get a system crash.

As far as I am aware, ELKS only supports SLIP connections via a serial 
port. The networking code has gone untested for a very long time. Most 
of us don't have an 8086-era machine connected to a modern PC via serial 
port with a SLIP server configured.

The TCP/IP/SLIP stack is in a binary called 'ktcp'. Given the fact that 
various annoying kernel and core utilities bugs still exist, most of the 
development focus has been on correcting those first. The lack of memory 
protection on the 8086 platform means any program has 'root'-level 
access to the entire system and situations that would cause a 
segmentation fault on Linux-i386 can easily take down the entire system 
on ELKS; this combined with the ease with which C lets you shoot 
yourself in the foot plus the severely limited program + data + stack 
space in the ELKS memory model makes "crashing" bugs more difficult to 
find and more important to catch.

If you want to start somewhere, look in the elks/Documentation 
directory. There should be info on how to use ktcp and SLIP to connect 
ELKS to an IP network. On the emulator side of things, you need to 
emulate a serial port and forward that serial port to a SLIP server in 
some roundabout manner, which is almost certainly the hard part these 
days since SLIP was outdated and mostly superseded by PPP in the mid-1990s.

Ideally, it would be better if we had an NE2000 Ethernet card driver; I 
once bought an NE2000-compatible 8-bit ISA card but the 8086 PC I had 
picked up (free) to put it in refused to boot from any media of any 
sort, so I unfortunately had to give up. My understanding is that the 
NE2000 is emulated by practically every single popular x86 emulation 
platform in existence and its interface is used by a huge variety of 
older network adapters; if someone feels like making ktcp talk NE2000, 
it would probably help on the networking side.

-Jody

Re: Elks networking

[Marc-François LUCCA-DANIAU]

> Ideally, it would be better if we had an NE2000 Ethernet card driver; My understanding is that the NE2000 is emulated by practically every single popular x86 emulation platform in existence and its interface is used by a huge variety of older network adapters; if someone feels like making ktcp talk NE2000, it would probably help on the networking side.

I am also interested in such NE2000 driver, because the ETH chip on my
SBC is an Asix AX88796-L, and according to its datasheet, it claims
"register level compatibility with NE2000".

MFLD


2016-05-29 8:31 GMT+02:00 Jody Bruchon <jody@jodybruchon.com>:
> On 2016-05-28 16:17, Derek Johansen wrote:
>>
>> Do sockets/networking work in elks and if so to what extent and in
>> what environment.  In my environment of elks on qemu on Ubuntu on Vbox
>> on win8.1 when I try to run telnet I get a system crash.
>
>
> As far as I am aware, ELKS only supports SLIP connections via a serial port.
> The networking code has gone untested for a very long time. Most of us don't
> have an 8086-era machine connected to a modern PC via serial port with a
> SLIP server configured.
>
> The TCP/IP/SLIP stack is in a binary called 'ktcp'. Given the fact that
> various annoying kernel and core utilities bugs still exist, most of the
> development focus has been on correcting those first. The lack of memory
> protection on the 8086 platform means any program has 'root'-level access to
> the entire system and situations that would cause a segmentation fault on
> Linux-i386 can easily take down the entire system on ELKS; this combined
> with the ease with which C lets you shoot yourself in the foot plus the
> severely limited program + data + stack space in the ELKS memory model makes
> "crashing" bugs more difficult to find and more important to catch.
>
> If you want to start somewhere, look in the elks/Documentation directory.
> There should be info on how to use ktcp and SLIP to connect ELKS to an IP
> network. On the emulator side of things, you need to emulate a serial port
> and forward that serial port to a SLIP server in some roundabout manner,
> which is almost certainly the hard part these days since SLIP was outdated
> and mostly superseded by PPP in the mid-1990s.
>
> Ideally, it would be better if we had an NE2000 Ethernet card driver; I once
> bought an NE2000-compatible 8-bit ISA card but the 8086 PC I had picked up
> (free) to put it in refused to boot from any media of any sort, so I
> unfortunately had to give up. My understanding is that the NE2000 is
> emulated by practically every single popular x86 emulation platform in
> existence and its interface is used by a huge variety of older network
> adapters; if someone feels like making ktcp talk NE2000, it would probably
> help on the networking side.
>
> -Jody
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Elks networking

[Alan]

> Ideally, it would be better if we had an NE2000 Ethernet card driver;
> I once bought an NE2000-compatible 8-bit ISA card but the 8086 PC I

If it was 8bit it was not NE2000 compatible but would be NE1000
compatible. It is possible to drive some NE2K clones in 8bit slots and
there is a special DOS packet driver for it, but a standard NE2000
driver won't work. A modified 3C509 driver also works with some PC/XT
class hardware.

Alan

Re: Elks networking

[Alan]

> I am also interested in such NE2000 driver, because the ETH chip on my
> SBC is an Asix AX88796-L, and according to its datasheet, it claims
> "register level compatibility with NE2000".

The best place to start are the DOS packet drivers which are GPL but in
8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
drivers they implement IRQ based receive notification and blocking
transmit in a tiny driver, which is the kind of model needed for a low
end CPU and something like ELKS.

As a chip it is pretty easy to drive although it is best to debug on an
emulator until it works as the real NE2000 has a very antisocial
attitude to incorrect I/O accesses (it hangs the machine solid).

On top of that you need an implementation of ARP and then the TCP/IP
stack.

Alan

Re: Elks networking

[Marc-F. LUCCA-DANIAU]

Not forgotten, and now tracked by:

https://github.com/mfld-fr/elks/issues/1

MFLD

Le 31/05/2016 à 12:50, Alan a écrit :
>> I am also interested in such NE2000 driver, because the ETH chip on my
>> SBC is an Asix AX88796-L, and according to its datasheet, it claims
>> "register level compatibility with NE2000".
> The best place to start are the DOS packet drivers which are GPL but in
> 8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
> drivers they implement IRQ based receive notification and blocking
> transmit in a tiny driver, which is the kind of model needed for a low
> end CPU and something like ELKS.
>
> As a chip it is pretty easy to drive although it is best to debug on an
> emulator until it works as the real NE2000 has a very antisocial
> attitude to incorrect I/O accesses (it hangs the machine solid).
>
> On top of that you need an implementation of ARP and then the TCP/IP
> stack.
>
> Alan
>

Re: Elks networking

[Marc-François LUCCA-DANIAU]

Not forgotten, and now tracked by:

https://github.com/mfld-fr/elks/issues/1

MFLD

>
> Le 31/05/2016 à 12:50, Alan a écrit :
>>>
>>> I am also interested in such NE2000 driver, because the ETH chip on my
>>> SBC is an Asix AX88796-L, and according to its datasheet, it claims
>>> "register level compatibility with NE2000".
>>
>> The best place to start are the DOS packet drivers which are GPL but in
>> 8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
>> drivers they implement IRQ based receive notification and blocking
>> transmit in a tiny driver, which is the kind of model needed for a low
>> end CPU and something like ELKS.
>>
>> As a chip it is pretty easy to drive although it is best to debug on an
>> emulator until it works as the real NE2000 has a very antisocial
>> attitude to incorrect I/O accesses (it hangs the machine solid).
>>
>> On top of that you need an implementation of ARP and then the TCP/IP
>> stack.
>>
>> Alan
>>
>

Re: Elks networking

[Marc-F. LUCCA-DANIAU]

Not forgotten, and now tracked by:

https://github.com/mfld-fr/elks/issues/1

MFLD

>
> Le 31/05/2016 à 12:50, Alan a écrit :
>>>
>>> I am also interested in such NE2000 driver, because the ETH chip on my
>>> SBC is an Asix AX88796-L, and according to its datasheet, it claims
>>> "register level compatibility with NE2000".
>>
>> The best place to start are the DOS packet drivers which are GPL but in
>> 8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
>> drivers they implement IRQ based receive notification and blocking
>> transmit in a tiny driver, which is the kind of model needed for a low
>> end CPU and something like ELKS.
>>
>> As a chip it is pretty easy to drive although it is best to debug on an
>> emulator until it works as the real NE2000 has a very antisocial
>> attitude to incorrect I/O accesses (it hangs the machine solid).
>>
>> On top of that you need an implementation of ARP and then the TCP/IP
>> stack.
>>
>> Alan
>>
>
.

Re: Elks networking

[Marc-François LUCCA-DANIAU]

Perhaps you meant "ez-dos" ?

As stated in a previous post by Alan, driving the old-fashion NE2K
chip (and compatible) through the ISA bus (or equivalent on embedded
system) is quite easy. I am currently writing the driver from scratch,
after reading the datasheet and being inspired by some other driver
implementations (DOS packet driver, BIOS diag, etc), to avoid any
license concern.

Any pointer to other implementation is welcome, for background
information and benchmarking purpose.

About integration of such driver in ELKS, the discussion is still open
today. Initial intent is to replace the low-level layer of KTCP that
sends / receives the packet on the /tty interface for SLIP, but it
appears that program needs to be reworked, to implement an ARP
transponder, and the driver needs to implement the select / poll
operations for efficient processing (as /tty that is selectable).

So I am focusing now on having a code that is able to configure the
PHY, to control the MAC to stack / unstack packets, and being notified
of packet reception. After this first step, I would deliver to Jody's
master and ask the community for guidelines for ELKS integration.

MFLD


2017-01-27 5:19 GMT+01:00 GOliath Keet <goliath.keet@gmail.com>:
> would any of the networking code from ez-nos be any good? that was open
> sourced a few years ago,
>
> I do have somewhere a email from the original author with permission to use
> his code,
>
> how difficult would it be to get a dos network driver to load as intended on
> elks? and then interface with that ?
>
> On Mon, Jan 23, 2017 at 7:48 PM, Marc-F. LUCCA-DANIAU <mfld.fr@gmail.com>
> wrote:
>>
>>
>> Not forgotten, and now tracked by:
>>
>> https://github.com/mfld-fr/elks/issues/1
>>
>> MFLD
>>
>>>
>>> Le 31/05/2016 à 12:50, Alan a écrit :
>>>>>
>>>>>
>>>>> I am also interested in such NE2000 driver, because the ETH chip on my
>>>>> SBC is an Asix AX88796-L, and according to its datasheet, it claims
>>>>> "register level compatibility with NE2000".
>>>>
>>>>
>>>> The best place to start are the DOS packet drivers which are GPL but in
>>>> 8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
>>>> drivers they implement IRQ based receive notification and blocking
>>>> transmit in a tiny driver, which is the kind of model needed for a low
>>>> end CPU and something like ELKS.
>>>>
>>>> As a chip it is pretty easy to drive although it is best to debug on an
>>>> emulator until it works as the real NE2000 has a very antisocial
>>>> attitude to incorrect I/O accesses (it hangs the machine solid).
>>>>
>>>> On top of that you need an implementation of ARP and then the TCP/IP
>>>> stack.
>>>>
>>>> Alan
>>>>
>>>

Fwd: Elks networking

[Marc-François LUCCA-DANIAU]

Sorry to have mixed "ez-Dos" and "ez-Nos"...

Thank you very much for the pointer and the fresh archival on GitHub.

It looks like that network stack contains some interesting stuff to
have a look on for the protocol implementation. I keep it under the
hand.

But after a quick parse, it looks also like that stack does not
contain any ethernet card driver, just the layer to connect through
the old serial line modems (SLIP and so on).

Reminds me the times of the singing modems at home...
tuuut-tuuut-pouic-diii-daaa-criiiicriiiicriiii... :-)

MFLD



---------- Forwarded message ----------
From: GOliath Keet <goliath.keet@gmail.com>
Date: 2017-01-28 18:23 GMT+01:00
Subject: Re: Elks networking
To: Marc-François LUCCA-DANIAU <mfld.fr@gmail.com>


The original Author has open sourced this code, and has corresponded
with me via email and reassured me, that he would like to see it used.

https://github.com/parabyte/ez-nos/archive/master.zip

Its like a unix environment for dos.

i hope something in there is useful for someone.

On Sat, Jan 28, 2017 at 7:50 AM, Marc-François LUCCA-DANIAU
<mfld.fr@gmail.com> wrote:
>
> Perhaps you meant "ez-dos" ?
>
> As stated in a previous post by Alan, driving the old-fashion NE2K
> chip (and compatible) through the ISA bus (or equivalent on embedded
> system) is quite easy. I am currently writing the driver from scratch,
> after reading the datasheet and being inspired by some other driver
> implementations (DOS packet driver, BIOS diag, etc), to avoid any
> license concern.
>
> Any pointer to other implementation is welcome, for background
> information and benchmarking purpose.
>
> About integration of such driver in ELKS, the discussion is still open
> today. Initial intent is to replace the low-level layer of KTCP that
> sends / receives the packet on the /tty interface for SLIP, but it
> appears that program needs to be reworked, to implement an ARP
> transponder, and the driver needs to implement the select / poll
> operations for efficient processing (as /tty that is selectable).
>
> So I am focusing now on having a code that is able to configure the
> PHY, to control the MAC to stack / unstack packets, and being notified
> of packet reception. After this first step, I would deliver to Jody's
> master and ask the community for guidelines for ELKS integration.
>
> MFLD
>
>
> 2017-01-27 5:19 GMT+01:00 GOliath Keet <goliath.keet@gmail.com>:
> > would any of the networking code from ez-nos be any good? that was open
> > sourced a few years ago,
> >
> > I do have somewhere a email from the original author with permission to use
> > his code,
> >
> > how difficult would it be to get a dos network driver to load as intended on
> > elks? and then interface with that ?
> >
> > On Mon, Jan 23, 2017 at 7:48 PM, Marc-F. LUCCA-DANIAU <mfld.fr@gmail.com>
> > wrote:
> >>
> >>
> >> Not forgotten, and now tracked by:
> >>
> >> https://github.com/mfld-fr/elks/issues/1
> >>
> >> MFLD
> >>
> >>>
> >>> Le 31/05/2016 à 12:50, Alan a écrit :
> >>>>>
> >>>>>
> >>>>> I am also interested in such NE2000 driver, because the ETH chip on my
> >>>>> SBC is an Asix AX88796-L, and according to its datasheet, it claims
> >>>>> "register level compatibility with NE2000".
> >>>>
> >>>>
> >>>> The best place to start are the DOS packet drivers which are GPL but in
> >>>> 8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
> >>>> drivers they implement IRQ based receive notification and blocking
> >>>> transmit in a tiny driver, which is the kind of model needed for a low
> >>>> end CPU and something like ELKS.
> >>>>
> >>>> As a chip it is pretty easy to drive although it is best to debug on an
> >>>> emulator until it works as the real NE2000 has a very antisocial
> >>>> attitude to incorrect I/O accesses (it hangs the machine solid).
> >>>>
> >>>> On top of that you need an implementation of ARP and then the TCP/IP
> >>>> stack.
> >>>>
> >>>> Alan
> >>>>
> >>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Elks networking

[Alan Cox]

On Sun, 29 Jan 2017 14:43:34 +0100
Marc-François LUCCA-DANIAU <mfld.fr@gmail.com> wrote:

> Sorry to have mixed "ez-Dos" and "ez-Nos"...
> 
> Thank you very much for the pointer and the fresh archival on GitHub.
> 
> It looks like that network stack contains some interesting stuff to
> have a look on for the protocol implementation. I keep it under the
> hand.
> 
> But after a quick parse, it looks also like that stack does not
> contain any ethernet card driver, just the layer to connect through
> the old serial line modems (SLIP and so on).
> 
> Reminds me the times of the singing modems at home...
> tuuut-tuuut-pouic-diii-daaa-criiiicriiiicriiii... :-)

Today I would like at some of the other stacks, in particular the uIP and
LWIP stacks. For Fuzix we are usign uIP in userspace with a similar kind
of messaging model (not quite the same as we buffer queued socket data to
disk due to lack of memory).

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Elks networking

[Georg Potthast]

Allan,

I was also looking into adding an ne2000 driver to ELKS but if you do that 
it is even better. This is the template I intended to start from:
https://github.com/RTEMS/rtems/blob/5eb769ca8b553b4378a773967f08de20847794db/c/src/lib/libbsp/i386/pc386/ne2000/ne2000.c

As a quick and dirty solution you could just replace the calls to the slip 
driver with calls to your ne2000 driver. This could be done with a 
compile-time option for a start. Making a proper layer with different 
network interfaces to choose from including an ifconfig utility can then be 
added later.

The slip driver exposes the functions slip_init(), slip_process() (i.e. 
Read) and slip_send(). These functions are called by the ktcp driver, in 
part via some other functions. So as you mentioned it is relatively easy to 
modify these function calls to call an ne2000 driver instead of slip.c.

Georg

--------------------------------------------------------------------------------------------------

Here are my notes about a tour of the network code in ELKS:

At system boot the code in „init/main.c“ is run which calls sock_init() in 
socket.c. This initializes, depending on the kernel configuration, the 
kernel interfaces in the files af_init.c (internet), af_unix.c (unix domain 
sockets) and af_nano.c.

These again call sock_register() in socket.c passing a structure with the 
functions they have implemented and their family name, e.g. „AF_INET“.

The common socket commands that ELKS supports i.e. socket, accept, bind, 
connect and listen are implemented in libc. In libc there are wrappers 
around kernel system calls which are implemented in socket.c. These system 
calls are sys_socket, sys_accept,  sys_bind, sys_connect and sys_listen. The 
application passes the family name with the command and this selects which 
of the kernel interfaces above will execute the command.

You can also use the read, write, select and close commands with the socket 
handle. These are executed with the sock_read, sock_write, sock_select and 
sock_close functions in socket.c.

So if the application executes a „write“ with the family „AF_INET“ the 
sock_write function in socket.c will translate this via structures of 
pointers into the function inet_write() in af_inet.c and execute that. This 
calls the function tcpdev_inetwrite() in our char/tcpdev driver which writes 
it into the „tdout_buf“ buffer. This buffer is then copied to memory in the 
tcpdev_read() function for the ktcp user space driver to pick up and send. 
On the other hand, the char/tcpdev driver will use the tcpdev_write function 
to copy received data to the kernel interface af_inet.c by calling the 
function inet_process_tcpdev() in that code.

There are two tcpdev.c files in the code. One, the „char/tcpdev“, is linked 
as a kernel driver  and the other, „ktcp/tcpdev“, handles the tcp part for 
the ktcp user mode driver.

When ktcp is started, it initializes several modules, first it calls 
tcpdev_init() which is implemented in ktcp/tcpdev.c. This opens the 
dev/tcpdev device that the kernel mode char/tcpdev driver has provided and 
receives the „tcpdevfd“ handle. Then the slip interface, ip, icmp, tcp and 
netconf are initialized. At the end ktcp calls its ktcp_run() function which 
does a while loop frequently calling tcp_process() in ktcp/tcpdev. The 
tcp_process() function queries the tcpdev device of the char/tcpdev driver 
for tasks to execute. In case of a write task, the function calls 
tcpdev_write which again calls tcp_output that implements retransmissions if 
necessary. It calls the function ip_sendpacket() in ip.c. This function 
again uses the function slip_send() in slip.c.

The loop in ktcp_run() also calls slip_process() in slip.c which handles the 
data received by calling ip_recvpacket() in ip.c.

HTH :)

-----Ursprüngliche Nachricht----- 
From: Marc-François LUCCA-DANIAU
Sent: Saturday, January 28, 2017 8:50 AM
To: ELKS
Subject: Re: Elks networking

Perhaps you meant "ez-dos" ?

As stated in a previous post by Alan, driving the old-fashion NE2K
chip (and compatible) through the ISA bus (or equivalent on embedded
system) is quite easy. I am currently writing the driver from scratch,
after reading the datasheet and being inspired by some other driver
implementations (DOS packet driver, BIOS diag, etc), to avoid any
license concern.

Any pointer to other implementation is welcome, for background
information and benchmarking purpose.

About integration of such driver in ELKS, the discussion is still open
today. Initial intent is to replace the low-level layer of KTCP that
sends / receives the packet on the /tty interface for SLIP, but it
appears that program needs to be reworked, to implement an ARP
transponder, and the driver needs to implement the select / poll
operations for efficient processing (as /tty that is selectable).

So I am focusing now on having a code that is able to configure the
PHY, to control the MAC to stack / unstack packets, and being notified
of packet reception. After this first step, I would deliver to Jody's
master and ask the community for guidelines for ELKS integration.

MFLD


2017-01-27 5:19 GMT+01:00 GOliath Keet <goliath.keet@gmail.com>:
> would any of the networking code from ez-nos be any good? that was open
> sourced a few years ago,
>
> I do have somewhere a email from the original author with permission to 
> use
> his code,
>
> how difficult would it be to get a dos network driver to load as intended 
> on
> elks? and then interface with that ?
>
> On Mon, Jan 23, 2017 at 7:48 PM, Marc-F. LUCCA-DANIAU <mfld.fr@gmail.com>
> wrote:
>>
>>
>> Not forgotten, and now tracked by:
>>
>> https://github.com/mfld-fr/elks/issues/1
>>
>> MFLD
>>
>>>
>>> Le 31/05/2016 à 12:50, Alan a écrit :
>>>>>
>>>>>
>>>>> I am also interested in such NE2000 driver, because the ETH chip on my
>>>>> SBC is an Asix AX88796-L, and according to its datasheet, it claims
>>>>> "register level compatibility with NE2000".
>>>>
>>>>
>>>> The best place to start are the DOS packet drivers which are GPL but in
>>>> 8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
>>>> drivers they implement IRQ based receive notification and blocking
>>>> transmit in a tiny driver, which is the kind of model needed for a low
>>>> end CPU and something like ELKS.
>>>>
>>>> As a chip it is pretty easy to drive although it is best to debug on an
>>>> emulator until it works as the real NE2000 has a very antisocial
>>>> attitude to incorrect I/O accesses (it hangs the machine solid).
>>>>
>>>> On top of that you need an implementation of ARP and then the TCP/IP
>>>> stack.
>>>>
>>>> Alan
>>>>
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html 

Re: Elks networking

[Georg Potthast 2]

My post was directed to Marc-François LUCCA-DANIAU and not to Alan, sorry about that.

Georg

> Georg Potthast <nospam@georgpotthast.de> hat am 29. Januar 2017 um 20:51 geschrieben:
> 
> 
> Allan,
> 
> I was also looking into adding an ne2000 driver to ELKS but if you do that 
> it is even better. This is the template I intended to start from:

Re: Elks networking

[Marc-François LUCCA-DANIAU]

Thanks Georg for the notes, I captured them in the file
/elks/elks/Documentation/text/networking.txt, that will be part of my
next commit.

MFLD


2017-01-29 20:51 GMT+01:00 Georg Potthast <nospam@georgpotthast.de>:
> Allan,
>
> I was also looking into adding an ne2000 driver to ELKS but if you do that
> it is even better. This is the template I intended to start from:
> https://github.com/RTEMS/rtems/blob/5eb769ca8b553b4378a773967f08de20847794db/c/src/lib/libbsp/i386/pc386/ne2000/ne2000.c
>
> As a quick and dirty solution you could just replace the calls to the slip
> driver with calls to your ne2000 driver. This could be done with a
> compile-time option for a start. Making a proper layer with different
> network interfaces to choose from including an ifconfig utility can then be
> added later.
>
> The slip driver exposes the functions slip_init(), slip_process() (i.e.
> Read) and slip_send(). These functions are called by the ktcp driver, in
> part via some other functions. So as you mentioned it is relatively easy to
> modify these function calls to call an ne2000 driver instead of slip.c.
>
> Georg
>
> --------------------------------------------------------------------------------------------------
>
> Here are my notes about a tour of the network code in ELKS:
>
> At system boot the code in „init/main.c“ is run which calls sock_init() in
> socket.c. This initializes, depending on the kernel configuration, the
> kernel interfaces in the files af_init.c (internet), af_unix.c (unix domain
> sockets) and af_nano.c.
>
> These again call sock_register() in socket.c passing a structure with the
> functions they have implemented and their family name, e.g. „AF_INET“.
>
> The common socket commands that ELKS supports i.e. socket, accept, bind,
> connect and listen are implemented in libc. In libc there are wrappers
> around kernel system calls which are implemented in socket.c. These system
> calls are sys_socket, sys_accept,  sys_bind, sys_connect and sys_listen. The
> application passes the family name with the command and this selects which
> of the kernel interfaces above will execute the command.
>
> You can also use the read, write, select and close commands with the socket
> handle. These are executed with the sock_read, sock_write, sock_select and
> sock_close functions in socket.c.
>
> So if the application executes a „write“ with the family „AF_INET“ the
> sock_write function in socket.c will translate this via structures of
> pointers into the function inet_write() in af_inet.c and execute that. This
> calls the function tcpdev_inetwrite() in our char/tcpdev driver which writes
> it into the „tdout_buf“ buffer. This buffer is then copied to memory in the
> tcpdev_read() function for the ktcp user space driver to pick up and send.
> On the other hand, the char/tcpdev driver will use the tcpdev_write function
> to copy received data to the kernel interface af_inet.c by calling the
> function inet_process_tcpdev() in that code.
>
> There are two tcpdev.c files in the code. One, the „char/tcpdev“, is linked
> as a kernel driver  and the other, „ktcp/tcpdev“, handles the tcp part for
> the ktcp user mode driver.
>
> When ktcp is started, it initializes several modules, first it calls
> tcpdev_init() which is implemented in ktcp/tcpdev.c. This opens the
> dev/tcpdev device that the kernel mode char/tcpdev driver has provided and
> receives the „tcpdevfd“ handle. Then the slip interface, ip, icmp, tcp and
> netconf are initialized. At the end ktcp calls its ktcp_run() function which
> does a while loop frequently calling tcp_process() in ktcp/tcpdev. The
> tcp_process() function queries the tcpdev device of the char/tcpdev driver
> for tasks to execute. In case of a write task, the function calls
> tcpdev_write which again calls tcp_output that implements retransmissions if
> necessary. It calls the function ip_sendpacket() in ip.c. This function
> again uses the function slip_send() in slip.c.
>
> The loop in ktcp_run() also calls slip_process() in slip.c which handles the
> data received by calling ip_recvpacket() in ip.c.
>
> HTH :)
>
> -----Ursprüngliche Nachricht----- From: Marc-François LUCCA-DANIAU
> Sent: Saturday, January 28, 2017 8:50 AM
> To: ELKS
> Subject: Re: Elks networking
>
> Perhaps you meant "ez-dos" ?
>
> As stated in a previous post by Alan, driving the old-fashion NE2K
> chip (and compatible) through the ISA bus (or equivalent on embedded
> system) is quite easy. I am currently writing the driver from scratch,
> after reading the datasheet and being inspired by some other driver
> implementations (DOS packet driver, BIOS diag, etc), to avoid any
> license concern.
>
> Any pointer to other implementation is welcome, for background
> information and benchmarking purpose.
>
> About integration of such driver in ELKS, the discussion is still open
> today. Initial intent is to replace the low-level layer of KTCP that
> sends / receives the packet on the /tty interface for SLIP, but it
> appears that program needs to be reworked, to implement an ARP
> transponder, and the driver needs to implement the select / poll
> operations for efficient processing (as /tty that is selectable).
>
> So I am focusing now on having a code that is able to configure the
> PHY, to control the MAC to stack / unstack packets, and being notified
> of packet reception. After this first step, I would deliver to Jody's
> master and ask the community for guidelines for ELKS integration.
>
> MFLD
>
>
> 2017-01-27 5:19 GMT+01:00 GOliath Keet <goliath.keet@gmail.com>:
>>
>> would any of the networking code from ez-nos be any good? that was open
>> sourced a few years ago,
>>
>> I do have somewhere a email from the original author with permission to
>> use
>> his code,
>>
>> how difficult would it be to get a dos network driver to load as intended
>> on
>> elks? and then interface with that ?
>>
>> On Mon, Jan 23, 2017 at 7:48 PM, Marc-F. LUCCA-DANIAU <mfld.fr@gmail.com>
>> wrote:
>>>
>>>
>>>
>>> Not forgotten, and now tracked by:
>>>
>>> https://github.com/mfld-fr/elks/issues/1
>>>
>>> MFLD
>>>
>>>>
>>>> Le 31/05/2016 à 12:50, Alan a écrit :
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am also interested in such NE2000 driver, because the ETH chip on my
>>>>>> SBC is an Asix AX88796-L, and according to its datasheet, it claims
>>>>>> "register level compatibility with NE2000".
>>>>>
>>>>>
>>>>>
>>>>> The best place to start are the DOS packet drivers which are GPL but in
>>>>> 8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
>>>>> drivers they implement IRQ based receive notification and blocking
>>>>> transmit in a tiny driver, which is the kind of model needed for a low
>>>>> end CPU and something like ELKS.
>>>>>
>>>>> As a chip it is pretty easy to drive although it is best to debug on an
>>>>> emulator until it works as the real NE2000 has a very antisocial
>>>>> attitude to incorrect I/O accesses (it hangs the machine solid).
>>>>>
>>>>> On top of that you need an implementation of ARP and then the TCP/IP
>>>>> stack.
>>>>>
>>>>> Alan
>>>>>
>>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Elks networking

[Alan Cox]

On Mon, 30 Jan 2017 21:08:24 +0100
Marc-François LUCCA-DANIAU <mfld.fr@gmail.com> wrote:

> Thanks Georg for the notes, I captured them in the file
> /elks/elks/Documentation/text/networking.txt, that will be part of my
> next commit.

If people are capturing ideas for fixing things there are two things I've
learned I wish I had known when I started ELKS.

1. Having a whole load of separate kernel stacks for each process all
mapped into kernel memory is a mistake. It turns out you get near enough
the same performance if keep the other kernel stacks in far memory and
"every" process has a stack (and possibly a fixed struct of objects you
reference a lot) that when in kernel is actually at the same place.

When you idle you sit in the idle loop (spinning executing hlt) and if
you schedule something other than idling to leave that you far memcpy the
old task stack out into task private memory and far copy the new one in.

That has two results. One (the important one for ELKS) is that all of a
sudden you've got *loads* of kernel data memory free and two (not so big
a deal for 8086), lots of references cease being foo->bar and become
static. 8086 is pretty good at pointers so it's not as big a deal there.

It slows task switching a tiny bit, but a single user box doesn't task
switch much except between idle and the previous task. On the other hand
the large amount of extra free kernel data space means more buffers and
drivers and rapidly turns it into a win even on performance.

2. The commercial 8086 Unix platforms actually didn't preallocate memory
or do chmem like hacks. Instead each process got allocated two chunks of
memory. CS pointed to the code one (which may be shared) and the code
runs from CS:0000 to CS:whatever. The clever bit is that the data segment
stretches from DS:0000 to DS:brk and stack from DS:sp to DS:FFFF. That
means each data/stack segment is always 64K long. However rather than
waste that memory the memory allocator actually interleaved processes -
that is the space between DS:brk and DS:sp of one process might be the
code or data of another.

This means they could always grow by swapping out/moving another task when
either the brk/sbrk() grew memory or the compiler assisted stack pointer
checking called the kernel to grow the stack.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Elks networking

[Georg Potthast 2]

There is a remark in the file documentation/text/memory:

"When the linker (ld) creates a binary it gives a default setting for chmem
(see writebin.c in the ld source). If you know that a particular program
uses little or no heap, you can patch bytes 24..27 in the executable to a
lower value: dseg+bseg+desired stack size."

So currently the stack is usually way too big. Usually a stack of 2k would be more than sufficient. This should be the default "desired stack size".

One could save a lot of memory if the loader would not just use the stack size ld86 has put into the executable header as its default, this means a data/stack segment of 64k, but to use the spezified bss size and a stack size of 2k instead. 

So I recommend to modify the loader to use just 2k as the stack size limit (a configurable option). Should this turn out to be insufficient for a program it will terminate with "stack overflow" and one could reconfigure this limit. With currently available programs for ELKS I do not think this will happen though.

Georg




> Alan Cox <alan@lxorguk.ukuu.org.uk> hat am 30. Januar 2017 um 22:59 geschrieben:
> 
> 2. The commercial 8086 Unix platforms actually didn't preallocate memory
> or do chmem like hacks. Instead each process got allocated two chunks of
> memory. CS pointed to the code one (which may be shared) and the code
> runs from CS:0000 to CS:whatever. The clever bit is that the data segment
> stretches from DS:0000 to DS:brk and stack from DS:sp to DS:FFFF. That
> means each data/stack segment is always 64K long. However rather than
> waste that memory the memory allocator actually interleaved processes -
> that is the space between DS:brk and DS:sp of one process might be the
> code or data of another.
> 
> This means they could always grow by swapping out/moving another task when
> either the brk/sbrk() grew memory or the compiler assisted stack pointer
> checking called the kernel to grow the stack.

Re: Elks networking

[One Thousand Gnomes]

> So I recommend to modify the loader to use just 2k as the stack size limit (a configurable option). Should this turn out to be insufficient for a program it will terminate with "stack overflow" and one could reconfigure this limit. With currently available programs for ELKS I do not think this will happen though.

No they'll crash the machine generally unless you are in 286 protected
mode. Most of the ELKS tools do build with their stack size set.

Alan