Ian Lance Taylor writes: > On Thu, Aug 29, 2019 at 5:15 PM George Hartzell <hartz...@alerce.com> wrote: > > > > Quick summary, I'm trying to understand the Go structures that cgo > > gives me, how they map back onto the C structures and why a Go struct > > that doesn't quite match the cgo output seems to work anyway. > > > > I've called out two explicit questions down below. > > > > --- > > > > The Linux kernel provides a character device interface to I2C devices, > > and the [i2c-tools] package provides a C library with "convenient" > > access functions. > > > > I'm working on a Go library for the kernel interface on a Raspberry > > Pi, because I need it for a project *and* as an etude [so please, > > don't do too much of my "homework" for me...;)] > > > > [...] > > This is not a helpful answer but I want to say that using "cgo > -godefs" in this way is not supported. You're welcome to use it but > it may well break in the future. The "-godefs" option is specifically > for generating files used in the syscall and golang.org/x/sys > packages, it's not intended for general use. We instead recommend > using import "C" and using cgo in the usual way as described at > https://golang.org/cmd/cgo/ and https://blog.golang.org/c-go-cgo .
@iant, thanks for the quick response. Everything's part of the lesson, so it's useful. Andrew's [c-go-cgo] article talks about an interface to a C library, while I'm trying to wrap a set of IOCTL calls into the kernel w/out requiring supporting C code. I suppose I *could* write a cgo library that would wrap the C-based [i2c-tools] library, but I wanted to do it directly in Go, without adding the [i2c-tools] dependency. Or, are you saying that I should create a package that does the `import "C"` and `import "unsafe"` and then somehow uses "C.Ioctl" (or something, I haven't dug very far into this line of thought yet...) to make the call into the kernel. I can see how every time such a thing was built it would use that Go version's latest/greatest understanding of how to map the Go and C structures, whereas the approach I'm copying is static and might become out of date. But, in that case, why do the things in golang.org/x/sys exist (though they're probably built for each release and are therefor up-to-date by def'n)? I thought that what I was doing here was essentially extending the set of syscalls (the C library in [i2c-tools] is "just" a set of wrappers around the IOCTL's associated with the Linux i2c character device interface), so the `cgo -godefs` usage was appropriate. While starting out on this, I found a series of discussions about adding various IOCTL calls to the golang.org/x/sys packages and pushback limiting what actually went in there. I thought that at a minimum additions needed to prove themselves "stand-alone" before making it into those packages. Thanks again for the time and thoughts, g. [c-go-cgo]: https://blog.golang.org/c-go-cgo [i2c-tools]: https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/23912.31528.829329.295650%40alice.local.
