soypat
commented
1 year ago Thank you so much for the work you put into this! I'm very excited about where this leads tinygo in the future.
A few comments:
net API change
It seems wise to minimize the surface change in net's exported API. The exported Netdev interface can go under tinygo-org/drivers.
Personally I would leave the exposed surface at this:
// Mirrors tinygo drivers.Netdev. Unexported to prevent use outside of tinygo
type netdev interface {
// drivers.Netdev methods
}
// UseNetdev sets the currently active network device for use with tinygo.
func UseNetdev(n netdev) {
netdev = n
}Reasons for this:
- packages that use
Netdevcan be compiled with native Go compiler. This may open doors in the future to a whole new area of Go development in embedded systems. - Netdev is a driver interface. The
driverspackage is perfectly well suited for it. - Not a fan of stutter in
net.Netdevername.drivers.Netdev,drivers.Socketis not that bad :eyes:
How to develop for lower level hardware?
Say I wanted to use a lower level Ethernet hardware like the ENC28J60. This IC requires the user to build packets from scratch basically, from the Ethernet to the TCP frame. I'm worried that the proposed API will be too high level for these devices. Back when I developed the driver for the ENC28J60 I came up with the following drivers interface:
```go
// Datagrammer represents a reader/writer of data packets received over stream.
// These packets are low level representations of what could be an Ethernet/IP/TCP transaction.
// An example of an IC which implements this is the ENC28J60.
type Datagrammer interface {
PacketWriter
PacketReader
}
// Packet represents a handle to a packet in an underlying stream of data.
type Packet interface {
io.Reader
// Discard discards packet data. Reader is terminated as well.
// If reader already terminated then it should have no effect.
Discard() error
}
// PacketReader returns a handle to a packet. Ideally there should be no more
// than one active handle at a time.
type PacketReader interface {
// Returns a Reader that reads from the next packet.
NextPacket(deadline time.Time) (Packet, error)
}
// PacketWriter handles writes to buffer. Writes are not sent over stream until Flush is called.
type PacketWriter interface {
io.Writer
// Flush writes buffer to the underlying stream.
Flush() error
}
```
Why compiler flags?
Why can't people simply start their main program with net.UseNetdev?
scottfeldman
bgould
sago35
deadprogram
Hi, I'd like to present an RFC for a network device driver model for Tinygo I've been working on. I call it netdev. It incorporates a socket-like API idea from @Justin A Wilson . ref: https://github.com/scottfeldman/tinygo/tree/netdev ref: https://github.com/scottfeldman/tinygo-drivers/tree/netdev
Goal
Provide a subset of functionality of the Go "net" package for Tinygo. Higher-level protocols, applications, and tests that depend on Go "net" will "just work" on Tinygo, as long as they use the subset.
The subset is:
Additional limitations:
Issues with current model
Duplication of code for higher-level protocols. See wifinina/http.go and rtl8720dn/http.go. Both implement "net/http" but do so in a device-dependent manner. "net/http" should be device-agnostic and built on "net" TCPConn, which hides the underlying device-specific code.
Duplication of code in tests and applications to initialize the network device. See examples/wifinina/tcpclient and examples/rtl8720dn/tcpclient. Same test, but with device-specific code for device initialization. There should be a single tcpclient test which uses "net" TCPConn.
Duplication of code in tests and applications to connect the network. Again, see examples/wifinina/tcpclient and examples/rtl8720dn/tcpclient. Same test, but with device-specific code for connecting to AP.
Introducing Netdev Driver Model
A netdev driver implements the Netdever interface:
Which includes a Socketer interface:
Higher protocols, applications and tests that want to use Go "net" package import the standard "net" package and silently the "netdev" package:
Network devices move to tinygo-drivers/netdev:
The netdev driver will register with a call to UseNetdev() in init() to set the active netdev. Which network device is registered depends on Tinygo build tags. See netdev/netdev_wifinina.go, for example, which registers wifinina only for these boards:
Tests move to tinygo-drivers/examples/net. Note that the tests are agnostic of the network device.
Finally, netdev settings such as Wifi SSID, passphrase are passed in with tinygo -ldflags option:
These settings are at the netdev level, and not the individual netdev driver (wifinina) level. So the command line above could target wioterminal by changing only the -target. The test to compile and the settings passed in don't change.