I think the question was intended to be more general, not just to fix this situation. If users are supposed to migrate from the syscall package to sys/unix then all functionality in syscall needs to be available in sys/unix. I don't think we want to have a mixture of references to syscall and sys/unix because then it will be confusing when to use which one.
Here are the issues that were found so far: syscall.Signal and syscall.Errno are used to convert signal and errno values to the appropriate integer type for the target platform. These can be handled as Ian suggests, by defining a type in sys/unix that implement the interface from os. There is also the struct SysProcAttr in syscall which does not appear in sys/unix, and is used by os. Not sure what to do with that. I will open an issue to follow up with these. On Tuesday, March 21, 2017 at 8:30:10 PM UTC-5, Ian Lance Taylor wrote: > > On Tue, Mar 21, 2017 at 12:21 PM, <chr...@linux.vnet.ibm.com > <javascript:>> wrote: > > We've found a bug in the syscall package (see > > https://github.com/opencontainers/runc/issues/1364), and the better > solution > > seems to be to move from syscall to sys. I've started updating some of > the > > runc code to see how big of a change it would be, and have gotten a bit > off > > in the weeds. I'd like some advice on how to properly switch over. > > > > The thing that is initially confusing me is the use of syscall's Signal. > For > > example, "sig := syscall.Signal(s)" (when handling signals a user might > send > > to a container's processes). Instead of using type syscall.Signal, is > there > > a sys type that is a direct replacement for Signal? It doesn't look like > it > > to me. > > > > I don't see a direct translation for Signal(0), either, and digging > around > > in the syscall code, nothing jumped out. > > > > It seems that it might be simplest to leave in syscall in some places > but > > use x/sys most of the time. > > Currently as you can see x/sys/unix still uses syscall.Signal. That > should probably be cleaned up with a new type defined in x/sys/unix > (that still implements the os.Signal interface). But the bug you are > encountering seems entirely independent of this Signal issue. I > wouldn't worry about tackling Signal just to fix some terminal ioctls. > > Ian > -- 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. For more options, visit https://groups.google.com/d/optout.
