From patchwork Thu Oct 11 03:32:00 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Eric W. Biederman" X-Patchwork-Id: 1580871 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 9A292DFB34 for ; Thu, 11 Oct 2012 03:32:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932494Ab2JKDcO (ORCPT ); Wed, 10 Oct 2012 23:32:14 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:50151 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755527Ab2JKDcN (ORCPT ); Wed, 10 Oct 2012 23:32:13 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1TM9VJ-0005Du-Re; Wed, 10 Oct 2012 21:32:09 -0600 Received: from [98.207.153.68] (helo=eric-ThinkPad-X220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1TM9VE-000427-9p; Wed, 10 Oct 2012 21:32:09 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Greg KH Cc: Kay Sievers , Linus Torvalds , Andy Walls , Al Viro , Mauro Carvalho Chehab , Ming Lei , Lennart Poettering , Linux Kernel Mailing List , Kay Sievers , Linux Media Mailing List , Michael Krufky , Ivan Kalvachev References: <506C562E.5090909@redhat.com> <20121003170907.GA23473@ZenIV.linux.org.uk> <20121003195059.GA13541@kroah.com> <3560b86d-e2ad-484d-ab6e-2b9048894a12@email.android.com> <87zk42tab4.fsf@xmission.com> <20121004174254.GA14301@kroah.com> Date: Wed, 10 Oct 2012 20:32:00 -0700 In-Reply-To: <20121004174254.GA14301@kroah.com> (Greg KH's message of "Thu, 4 Oct 2012 10:42:54 -0700") Message-ID: <87626hr8en.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=; ; ; mid=; ; ; hst=in01.mta.xmission.com; ; ; ip=98.207.153.68; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX1+Msk7EuXujwaRhu66uIhVHxP9K+fVJXAo= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sa02.xmission.com X-Spam-Level: X-Spam-Status: No, score=-4.0 required=8.0 tests=ALL_TRUSTED,BAYES_00, DCC_CHECK_NEGATIVE,T_TM2_M_HEADER_IN_MSG,T_XMDrugObfuBody_08 autolearn=disabled version=3.3.2 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Greg KH X-Spam-Relay-Country: Subject: Re: udev breakages - X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Greg KH writes: > On Thu, Oct 04, 2012 at 10:29:51AM -0700, Eric W. Biederman wrote: >> There are still quite a few interesting cases that devtmpfs does not >> even think about supporting. Cases that were reported when devtmpfs was >> being reviewed. > > Care to refresh my memory? Anyone who wants something besides the default policy. Containers chroots anyone who doesn't want /dev/console to be c 5 1. >> Additionally the devtmpfs maintainership has not dealt with legitimate >> concerns any better than this firmware issue has been dealt with. I >> still haven't even hear a productive suggestion back on the hole >> /dev/ptmx mess. > > I don't know how to handle the /dev/ptmx issue properly from within > devtmpfs, does anyone? Proposals are always welcome, the last time this > came up a week or so ago, I don't recall seeing any proposals, just a > general complaint. The proposal at that time was to work around the silliness with a little kernel magic. To recap for those who haven't watched closely. devpts now has a ptmx device node and it would be very nice if we were to use that device node instead of /dev/ptmx. Baically it would be nice to tell udev to not create /dev/ptmx, and instead to make /dev/ptmx a symlink to /dev/pts/ptmx. I got to looking at the problem and if I don't worry about systemd and just look at older versions of udev that are out there in the wild it turns out the following udev configuratoin line does exactly what is needed. It creats a symlink from /dev/ptmx to /dev/pts/ptmx. And if on the odd chance devpts is not mounted it creates /dev/pts/ptmx as well. KERNEL=="ptmx" NAME:="pts/ptmx" SYMLINK="ptmx" Does assigning to NAME to specify the device naming policy work in systemd-udev or has that capability been ripped out? Thinking about it. Since systemd-udev no longer supports changing the device name. And likely it no longer even supports assigning to NAME even for purposes of changing the target of the symlink. Then I expect what we want to do is: Eric --- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/base/devtmpfs.c b/drivers/base/devtmpfs.c index 147d1a4..7dc5bed 100644 --- a/drivers/base/devtmpfs.c +++ b/drivers/base/devtmpfs.c @@ -377,6 +377,7 @@ static int devtmpfsd(void *p) goto out; sys_chdir("/.."); /* will traverse into overmounted root */ sys_chroot("."); + sys_symlink("pts/ptmx", "ptmx"); complete(&setup_done); while (1) { spin_lock(&req_lock);