Message-ID: <9b2b86520905011413y21195335mbaaf08feb49f6bee@mail.gmail.com>
Date:	Fri, 1 May 2009 22:13:42 +0100
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Greg KH <greg@...ah.com>
Cc:	Chris Wedgwood <cw@...f.org>, Kay Sievers <kay.sievers@...y.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 5/1/09, Greg KH <greg@...ah.com> wrote:
> On Fri, May 01, 2009 at 04:43:49PM +0100, Alan Jenkins wrote:
>> On 5/1/09, Greg KH <greg@...ah.com> wrote:
>> > On Thu, Apr 30, 2009 at 11:57:54PM -0700, Chris Wedgwood wrote:
>> >> On Thu, Apr 30, 2009 at 03:23:42PM +0200, Kay Sievers wrote:
>> >>
>> >> > Devtmpfs lets the kernel create a tmpfs very early at kernel
>> >> > initialization, before any driver core device is registered. Every
>> >> > device with a major/minor will have a device node created in this
>> >> > tmpfs instance. After the rootfs is mounted by the kernel, the
>> >> > populated tmpfs is mounted at /dev. In initramfs, it can be moved to
>> >> > the manually mounted root filesystem before /sbin/init is executed.
>> >>
>> >> Why can't the initramfs create /dev and populate it?
>> >
>> > Right now it does, and it takes about 1-2 seconds to do so depending on
>> > the hardware.
>> >
>> > Which is over double the time it takes to boot the kernel entirely these
>> > days, so it is quite noticable.
>>
>> Please, this argument is pants.
>
> Is that short pants?  Jeans?  Khakis?  What color? :)

Damned international communication :-).

   Adjective
    pants (comparative more pants, superlative most pants)

    (British, slang) Of inferior quality, rubbish
    Your mobile is pants — why don’t you get one like mine?

And - apologies, for raising my voice for something which doesn't deserve it.

>> The initramfs _could_  create /dev and populate it.
>
> How?  With a bash script like Android does?  Do you want to maintain two
> different code streams for this kind of thing?

I hypothesized a small, "obviously correct", C program.  It would make
sense to maintain it as part of udev.  Seeing as most initramfs' will
still use udev, and just ask it to do less.

>> Neither crawling /sys or creating device nodes is horribly expensive.
>
> No, but it is measurable.
>
>> It's udev that adds overhead which is not needed at this point.
>> If the initramfs was optimised to do the same as devtmpfs, it needn't
>> take more than 50ms on my eeepc.
>
> It would take longer than 50ms.

> But first, time it with an initramfs with the load time of your script
> and the rest of the stuff you need to do there to get it running.  And
> also drop your caches before doing such a test as well to make it
> "real".

I was trying to measure the system calls required.  I'm all too aware
of the overhead of fork() even without exec(), so I wouldn't write it
in shell.  And I was comparing initramfs w/"makedev.c" to initramfs
w/devtmpfs.

>> If this deserves to live in the kernel, let's not pretend that it is
>> because it works dramatically faster.
>
> But it does.
>
> And it's also a solution for the embedded people, and the rescue disk
> users, and the others of us that have to drop down to init=/bin/bash at
> times.
>
> If you don't like it,

I said upthread that I would love it for all of those reasons.
Seriously, I've done all three in the past, this sounds pretty
attractive.

I'm trying to gain an honest understanding of the idea, and what it
will mean, in part by comparing it to the alternatives.  I am very
confused when you answer "why put this in the kernel" with "it's too
slow at the moment", because there is no _direct_ connection between
the two.

I think what your answer missed is that you're making the process much
_simpler_, which explains both why it can be faster, and why it should
be considered as a legitimate role for the kernel.

<deleted comprehensive notes which explain the nature of the
simplification among other things, but probably aren't worth restating
here>.

The problem is that the simplification is the important part of the
change, it has tradeoffs, and glossing over tradeoffs can come over
all suspicious.  But I'm happy  that Kay's taken the time to answer
all the questions I had now.

> don't build it into your kernel, it's only 300
> lines of code to keep away from your machine.

I refuse to rise to that :).  I think on the contrary, it will become
difficult to disable when future initramfs' rely on it.  But I won't
want to at that point.

Thanks
Alan
--
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