SGTM

On 7 Oct 2015, at 02:19, Kim Shrier notifications@github.com wrote:

Continuing along the lines of adding terminal support, I propose to add the functions:

Tcdrain
Tcflow
Tcflush
Tcgetattr
Tcgetpgrp
Tcgetsid
Tcsendbreak
Tcsetattr
Tcsetpgrp
Along with constant definitions for:

TCIOFF
TCION
TCOOFF
TCOON
TCSADRAIN
TCSANOW
The source changes are fairly trivial and I have tested them for solaris. Adding this code to x/sys/unix means that you don't need to have cgo code in a higher level terminal package.

—
Reply to this email directly or view it on GitHub.

Adding constant definitions sounds good to me
(if they are used directly in ioctl, see below.)

But those tc* functions are syscalls, but wrappers
around ioctl (at least on Linux, please correct me
if I'm mistaken), so I'd prefer to add them into
a separate x/sys/unix/termios package instead.

The API surface for x/sys/unix is already too large,
I'd prefer more specific features be added to a
dedicated package instead.

That said, adding those tc* functions to Solaris
port of x/sys/unix SGTM due to peculiarity of the
platform.

If people think it is a good thing to place the tc* functions in a separate package for one GOOS/GOARCH combination, I would think it makes sense to do it for all supported GOOS/GOARCH combinations. My question is would it be x/sys/unix/termios or x/sys/termios. I believe Plan9 and Windows have these functions available so would think the package wouldn't go under x/sys/unix.

My suggestion is sys/term which encompasses terminal like things across all
platforms. If unix termos like things need to be added, I think they should
go in sys/unix.

Thanks

Dave

On Thu, Oct 8, 2015 at 2:50 AM, Kim Shrier notifications@github.com wrote:

If people think it is a good thing to place the tc* functions in a
separate package for one GOOS/GOARCH combination, I would think it makes
sense to do it for all supported GOOS/GOARCH combinations. My question is
would it be x/sys/unix/termios or x/sys/termios. I believe Plan9 and
Windows have these functions available so would think the package wouldn't
go under x/sys/unix.

—
Reply to this email directly or view it on GitHub
#12853 (comment).

I think we can decline this in favor of #13104 (not that 13104 is completely decided yet).

x/sys really is about system calls and the line has to be drawn there. Otherwise x/sys will become a kitchen sink.