x/sys/unix: Add support for SocketCAN

[elliotmr]

The unix.Sockaddr interface has a package local method and therefore cannot be implemented outside of the golang.org/x/sys/unix package, and without an appropriate Sockaddr structure for CAN it is impossible to create a SocketCAN socket type. (See discussion here: https://groups.google.com/forum/#!topic/golang-nuts/5HTN3QVC_lQ).

The proposal is to add a SockaddrCAN struct for wrapping the sockaddr_can structure defined in <linux/can.h> so that SocketCAN can use all the socket related functions from the package.

Patch: https://github.com/elliotmr/cantest/blob/master/unix.diff
Test Code: https://github.com/elliotmr/cantest

[fhedberg]

What's the status on this? Would be great to get this merged.

[bradfitz]

This is how we do code review & patch merging: https://golang.org/doc/contribute.html

Yes, it's wordy (#17802 tracks shortening it), but it's the only way.

[elliotmr]

I will try to follow through with the gerrit submission on the weekend.

[rumpelsepp]

@elliotmr Also, do not forget the BCM Sockets. :)

[elliotmr]

@rumpelsepp This change is just for the Sockaddr structure, so that we create the correct socket type, it doesn't even add the can_frame struct let alone the BCM structs.

However, there is no problem adding those in a user library because there is no need to access a private interface.

[gopherbot]

CL https://golang.org/cl/33392 mentions this issue.

[elliotmr]

I am not sure about how to leave a general comment in gerrit, so I will leave it here.

I am not exactly sure what to do with the generated files. I ran mkall.sh on my development computer which is amd64 and on a qemu emulated arm system. However, both results were substantially different in all the ztypes__, zsysnum__, and zerrors_* files. I ended up cherry picking the relevant changes for ztypes from the generation and I left out the rest of the changes. Is this the correct approach?

Also, I don't have the infrastructure to regenerate all the architectures, how is this normally handled?

[ianlancetaylor]

Cherry picking the required changes is the right approach.

Do the types and numbers vary across architectures?

[elliotmr]

As far as I understand, everything should be architecture independent.

I can just copy the generated code to the other architecture specific files if that is the way to go.

[ianlancetaylor]

Yes, that is fine. Thanks.

[axlrose]

set can filter frame

const CAN_RAW_FILTER = 0x01
type CanId_t uint32

type Can_Filter struct {
	Can_id   CanId_t
	Can_mask CanId_t
}
func SetsockoptCanFilter(fd, level, opt int, filter_tbl []Can_Filter) (err error) {
	filter_cnt := len(filter_tbl)
	var vlen = uint(filter_cnt * 8)
	return unix.Setsockopt(fd, level, opt, unsafe.Pointer(&filter_tbl[0]), uintptr(vlen))
}    

    rfilter := make([]Can_Filter, 4)
	rfilter[0].Can_id = 0x123
	rfilter[0].Can_mask = unix.CAN_SFF_MASK
	rfilter[1].Can_id = 0x124
	rfilter[1].Can_mask = unix.CAN_SFF_MASK
	rfilter[2].Can_id = 0x125
	rfilter[2].Can_mask = unix.CAN_SFF_MASK
	rfilter[3].Can_id = 0x126
	rfilter[3].Can_mask = unix.CAN_SFF_MASK

	if err = SetsockoptCanFilter(fd, SOL_CAN_RAW, CAN_RAW_FILTER, rfilter); err != nil {
              return err
        }

unix.setsockopt -> unix.Setsockopt

[ianlancetaylor]

@axlrose I'm not sure what you are trying to say, but this issue is closed. Please use a form (https://golang.org/wiki/Questions) or open a new issue.