From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755526AbZEJA5T (ORCPT ); Sat, 9 May 2009 20:57:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754111AbZEJA5H (ORCPT ); Sat, 9 May 2009 20:57:07 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:28257 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754095AbZEJA5E (ORCPT ); Sat, 9 May 2009 20:57:04 -0400 MIME-Version: 1.0 In-Reply-To: References: <1241097822.2516.3.camel@poy> From: Kay Sievers Date: Sun, 10 May 2009 02:56:44 +0200 Message-ID: Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs To: "Eric W. Biederman" Cc: linux-kernel , Greg KH , Jan Blunck Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 10, 2009 at 02:29, Eric W. Biederman wrote: > Kay Sievers writes: > >> On Thu, May 7, 2009 at 10:17, Eric W. Biederman wrote: >> >>> sysfs is slow. >>> udev is slow. >> >> Everything is "slow" if you want to boot "fast". It's just numbers, >> and this is more about simplicity and reliability, with just the side >> effect that it's the fastest you can do, when you don't want to lose >> current functionality. > > My primary concern is that you are inventing a new mechanism when > the existing mechanism has known issues that could explain the slowdowns. You mean that mounting a new tmpfs at /dev has the issue of being empty? And it takes time to fill it, where you can't reliably do other things at the same time that might need device nodes? Yeah, I guess that's an issue with the existing mechanism, and I'm interested in your proposal to solve it. Thanks, Kay