[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090205002757.GA18758@us.ibm.com>
Date: Wed, 4 Feb 2009 18:27:57 -0600
From: "Serge E. Hallyn" <serue@...ibm.com>
To: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Cc: linux-kernel@...r.kernel.org, hpa@...or.com,
Containers <containers@...ts.osdl.org>, hch@....de,
Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [v2][PATCH 1/5] Unroll essentials of do_remount_sb() into
devpts
Quoting Serge E. Hallyn (serue@...ibm.com):
> Quoting Sukadev Bhattiprolu (sukadev@...ux.vnet.ibm.com):
> >
> > From: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
> > Date: Tue, 27 Jan 2009 22:58:18 -0800
> > Subject: [v2][PATCH 1/5] Unroll essentials of do_remount_sb() into devpts
> >
> > On remount, devpts fs only needs to parse the mount options. Users cannot
> > directly create/dirty files in /dev/pts so the MS_RDONLY flag and
> > shrinking the dcache does not really apply to devpts.
> >
> > So effectively on remount, devpts only parses the mount options and updates
> > these options in its super block. As such, we could replace do_remount_sb()
> > call with a direct parse_mount_options().
> >
> > Doing so enables subsequent patches to avoid parsing the mount options twice
> > and simplify the code.
>
> You've dropped the update_ptmx_mode() which you used to do
> inside devpts_remount(). Is that also on purpose?
Since it appears that mknod_ptmx() will be called anyway and
will do the same thing,
> > Signed-off-by: Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Acked-by: Serge Hallyn <serue@...ibm.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists