Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751383AbdGQOmB (ORCPT ); Mon, 17 Jul 2017 10:42:01 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:36344 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751300AbdGQOmA (ORCPT ); Mon, 17 Jul 2017 10:42:00 -0400 Date: Mon, 17 Jul 2017 16:41:54 +0200 From: Greg KH To: Masatake YAMATO Cc: linux-kernel@vger.kernel.org, jslaby@suse.com Subject: Re: [PATCH RESEND] pty: show associative slave of ptmx in fdinfo Message-ID: <20170717144154.GA26498@kroah.com> References: <20170712193437.3789-1-yamato@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170712193437.3789-1-yamato@redhat.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1396 Lines: 40 On Thu, Jul 13, 2017 at 04:34:37AM +0900, Masatake YAMATO wrote: > This patch adds "tty-index" field to /proc/PID/fdinfo/N if N > specifies /dev/ptmx. The field shows the index of associative > slave pts. > > Though a minor number is given for each pts instance, ptmx is not. > It means there is no way in user-space to know the association between > file descriptors for pts/n and ptmx. (n = 0, 1, ...) > > This is different from pipe. About pipe such association can be solved > by inode of pipefs. > > Providing the way to know the association between pts/n and ptmx helps > users understand the status of running system. lsof can utilize this field. > > Signed-off-by: Masatake YAMATO > --- > drivers/tty/pty.c | 12 +++++++++++- > drivers/tty/tty_io.c | 15 +++++++++++++++ > include/linux/tty_driver.h | 5 +++++ > 3 files changed, 31 insertions(+), 1 deletion(-) > > diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c > index 6579957..9357c6a 100644 > --- a/drivers/tty/pty.c > +++ b/drivers/tty/pty.c > @@ -669,6 +669,13 @@ static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty) > } > } > > +#ifdef CONFIG_PROC_FS There is no real need for all of the #ifdef everywhere here, if PROC_FS is not enabled, the functions will just not be called, right? Can you fix this up and resend a new version? thanks, greg k-h