Guidelines to plug NE2K driver in ELKS

Guidelines to plug NE2K driver in ELKS

[Marc-F. LUCCA-DANIAU]

Hello all,

As suggested by Alan and Jody, I delivered a standalone code to drive 
the NE2K in /elks/arch/i86/drivers/net as a first step, and I intend to 
connect it to the low end of KTCP (in parallel of SLIP) as a second step.

But because KTCP needs a "selectable" device to operate, and because I 
am not at ease with the select / poll implementation in ELKS, could I 
have some guidelines to integrate the current standalone code ?

Thanks,

MFLD

Re: Guidelines to plug NE2K driver in ELKS

[Georg Potthast]

Hello Marc-F.,

this is what I could make out so far. The functions that support "select" 
are implemented in elks/fs/select.c. KTCP does the following select call: 
„select(sfd > tcpdevfd ? sfd + 1 : tcpdevfd + 1,  &fdset, NULL, NULL, tv);“ 
In there sfd is the file descriptor for slip and tcpdevfd is the file 
descriptor for the tcpdev device.

The tcpdev device has made its tcp_select() function known to the kernel 
using the tcp_fops structure via the register_chrdev() function. The kernel 
calls this function when loading the module. So the kernel can call 
tcp_select() to determine if there is anything to do.

After slip opens the ttySx device, the kernel will query the tty_select() 
function in the arch/i86/drivers/char/ntty driver. I think that again calls 
rs_ioctl() in serial.c. The structure "tty" which is returned by this 
function contains a pointer to the queue of received chars and the select 
function in ntty uses that to determine if data has been received and is 
available for a read call.

One could probably just make a quick and dirty solution and poll the network 
card code for data from the ktcp_run() loop without select. The slip_process 
function just returns if no data has been read.

To follow the Linux structure, however, you would have to write an „ethx“ 
device driver which supports a select call from the kernel.

I am about to finish an "Introduction to ELKS" document this week. The 
document is intended to provide a quick start for new users/developers of 
ELKS. This document contains a chapter how to write a kernel mode driver for 
ELKS although is not typically part of an introduction. If you have not 
written such a driver yet this could be of help for developing an „ethx“ 
device driver.

Georg

-----Ursprüngliche Nachricht----- 
From: Marc-F. LUCCA-DANIAU
Sent: Sunday, February 5, 2017 12:12 PM
To: ELKS
Subject: Guidelines to plug NE2K driver in ELKS

Hello all,

As suggested by Alan and Jody, I delivered a standalone code to drive
the NE2K in /elks/arch/i86/drivers/net as a first step, and I intend to
connect it to the low end of KTCP (in parallel of SLIP) as a second step.

But because KTCP needs a "selectable" device to operate, and because I
am not at ease with the select / poll implementation in ELKS, could I
have some guidelines to integrate the current standalone code ?

Thanks,

MFLD


--
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: Guidelines to plug NE2K driver in ELKS

[Marc-F. LUCCA-DANIAU]

Hello all,

An alpha version of the NE2K driver is now available in Jody's master 
branch.

The strong limitation is the missing management of the NE2K ring 
overflow, that has been delayed to a next integration step. So this 
driver should not be used in a heavily loaded network for the moment.

We are now working on KTCP to add the Ethernet path, an ARP transponder 
and a basic IP routing.

Thanks to Georg for his support on that sub-project.

MFLD


Le 05/02/2017 à 12:12, Marc-F. LUCCA-DANIAU a écrit :
> Hello all,
>
> As suggested by Alan and Jody, I delivered a standalone code to drive 
> the NE2K in /elks/arch/i86/drivers/net as a first step, and I intend 
> to connect it to the low end of KTCP (in parallel of SLIP) as a second 
> step.
>
> But because KTCP needs a "selectable" device to operate, and because I 
> am not at ease with the select / poll implementation in ELKS, could I 
> have some guidelines to integrate the current standalone code ?
>
> Thanks,
>
> MFLD
>
>