linux-kernel - Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1skjd4x7o.fsf@fess.ebiederm.org>
Date:	Sat, 09 May 2009 17:29:15 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>, Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs

Kay Sievers <kay.sievers@...y.org> writes:

> On Thu, May 7, 2009 at 10:17, Eric W. Biederman <ebiederm@...ssion.com> 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.

My secondary concern is we have are adding a new mechanism when
the existing mechanism has some significant known issues, that are
not currently being addressed.  Instead the next shiny bobble is
being tackled.

Finally I am stumped how creating a couple hundred device nodes can be
a significant slowdown in booting.  It feels like we your patchset
adds a line of code for each device node it intends to create.

>> Let's bloat the kernel to solve that problem?
>
> You want to add namespaces for devices to it?

I think it is a logical conclusion, and it might potentially be needed.
But that is a long ways out.

Eric
--
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/