From: Georg Potthast 2 <nospam@georgpotthast.de>
To: ELKS <Linux-8086@vger.kernel.org>,
"Marc-F. LUCCA-DANIAU" <mfld.fr@gmail.com>
Subject: Re: Moved eth_* to ne2k_* for future expansion
Date: Mon, 6 Mar 2017 13:28:44 +0100 (CET) [thread overview]
Message-ID: <1300581257.173577.1488803325070@com4.strato.de> (raw)
In-Reply-To: <bfee1afb-1bd5-b43d-757e-3920b0c81f7a@gmail.com>
Marc-F.,
maybe someone else will find a way to support PCI using 16bit code in the future and will want to add an additional driver. So I would use a code structure which allows for additional NIC drivers.
I know supporting wireless is difficult but it would be an interesting addition.
Georg
> "Marc-F. LUCCA-DANIAU" <mfld.fr@gmail.com> hat am 5. März 2017 um 22:30 geschrieben:
>
>
> Sorry Georg, but I won't spend any time in supporting more Ethernet
> devices, because I think that:
>
> 1) NE2K is the only ISA device provided by QEMU, other need PCI support,
> and ELKS has no PCI support. I don't think adding PCI support would be
> in the scope of this project, because PCI came with the 32 bits generation.
>
> 2) My goal is to run ELKS on my real SBC, that has a NE2K clone chip. I
> am therefore not interested in any other Ethernet chip.
>
> 3) ELKS is missing the network driver framework, so a discussion for a
> generic driver is biased by this limitation. IMHO, the best driver
> framework is one generic Ethernet driver, and specialized packet
> drivers, with a standard "packet ops" interface for clean branching. The
> template you are dealing with should be not at Ethernet driver level,
> but at packet driver level. But again, back to 1) and 2), I see no need
> to develop that framework.
>
> MFLD
>
>
> Le 05/03/2017 à 21:37, Georg Potthast a écrit :
> > When I look at the drivers in the char directory, most implement their
> > own version of a fops structure and have an init function for the
> > kernel. So I would expect that an RTL NIC driver would have the same
> > structure as the NE2K driver, again with a fops structure and an init
> > function. I would rather use this template than branch to various
> > specific functions from a generic ethernet driver. This mainly because
> > that has been the pattern used by ELKS so far and the developers may
> > be more familiar with it.
> >
> > The *_un and *_in files have been deleted in the
> > "elkscmd/test/socket/echo" directory and are replaced with echoserver
> > and echoclient files that will use unix domain sockets if "-u" is
> > passed on the command line.
> >
> > Georg
> >
> > -----Ursprüngliche Nachricht----- From: Marc-François LUCCA-DANIAU
> > Sent: Saturday, March 4, 2017 6:48 PM
> > To: ELKS
> > Subject: Re: Moved eth_* to ne2k_* for future expansion
> >
> > OK for the changes that seem logical to me, except:
> >
> > * elks/arch/i86/drivers/net/ne2k-main.c : I actually planned to rename
> > this file eth-main.c, because the pattern of any Ethernet driver is
> > the same, and will implement the same "fops". Only the call to ne2k_*
> > functions are specific. So we should keep the eth_* functions inside
> > this module, that are generic.
> >
> > * elks/arch/i86/drivers/net/ne2k-test.c : renaming the variables
> > related to Ethernet protocol and not linked to the NE2K has no sense :
> > ne2k_from and ne2k_to, for example, are MAC adresses, and do not
> > depend on the underlying Ethernet device. So we should rename them
> > back to eth_from and eth_to.
> >
> > * elkscmd/test/socket/echo/.gitignore : I believe that Georg removed
> > *_un and *_in programs, and replaced them by more generic programs ?
> > If confirmed, remove *_un and *_in.
> >
> > * qemu.sh : "system" keyword means that we use the "QEMU system
> > emulator". Not the "QEMU program emulator", that is not the same. So
> > keep that accurate comment.
> >
> > MFLD
> >
> >
> >
> >
> > 2017-03-04 17:46 GMT+01:00 Jody Bruchon <jody@jodybruchon.com>:
> >> I generalized some network stuff in case other network adapters are
> >> supported in the future. Make sure I didn't break anything,
> >>
> >> -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
> > --
> > 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
prev parent reply other threads:[~2017-03-06 12:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-04 16:46 Moved eth_* to ne2k_* for future expansion Jody Bruchon
2017-03-04 17:48 ` Marc-François LUCCA-DANIAU
2017-03-05 20:37 ` Georg Potthast
2017-03-05 21:30 ` Marc-F. LUCCA-DANIAU
2017-03-06 12:28 ` Georg Potthast 2 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1300581257.173577.1488803325070@com4.strato.de \
--to=nospam@georgpotthast.de \
--cc=Linux-8086@vger.kernel.org \
--cc=mfld.fr@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).