[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac3eb2510905010624k891f680s7255af8ae185b5d5@mail.gmail.com>
Date: Fri, 1 May 2009 15:24:01 +0200
From: Kay Sievers <kay.sievers@...y.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Greg KH <greg@...ah.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Jan Blunck <jblunck@...e.de>
Subject: Re: [PATCH] driver-core: devtmpfs - driver core maintained /dev tmpfs
On Fri, May 1, 2009 at 15:18, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
>> No tool ever has a chance to get to the information only available at
>> early kernel init. All such tools will need to "replay" what the
>> kernel already did. This is intended to save us from doing this, and
>> retain the information which is there, but lost at the moment the
>> tools have the first chance to run.
>
> Serious question - which is the better problem to fix ?
I'm very sure, you can not fix it outside the kernel. Or do you have
an idea how to create the missing device nodes for device without
crawling sysfs, when the first userspace process is started?
>> It's not about a sucking tool, its just impossible. And there is no
>> space wasted, it's a single string for a very few subsystems, an
>> nothing is stored per device.
>
> Plus code plus tmpfs nodes (the latter are not quite free because you
> create unneeded ones versus udev but I agree that is noise for most users)
It's exactly the same as udev. Udev creates a node for every device
the core registers in tmpfs. This tmpfs is mounted by the kernel and
pre-populated with this, not by udev, that's all the difference it
has. There is not a single node more than before.
Thanks,
Kay
--
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