From: Bill Gatliff <bgat@billgatliff.com>
To: linux-kernel@vger.kernel.org
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date: Wed, 22 Jun 2005 21:13:47 -0500 [thread overview]
Message-ID: <42BA1ADB.6090006@billgatliff.com> (raw)
In-Reply-To: <20050622181825.204fbcb7.akpm@osdl.org>
Andrew:
>>It breaks a lot of my embedded setups which have read-only storage only
>>and thus need /dev on devfs or tmpfs.
>>
>>
>
>Well that's quite a problem. We're certainly causing people such as
>yourself to take on quite a lot of work. But on the other hand we do want
>the kernel to progress sanely, and that sometimes involves taking things
>out.
>
>I don't have enough info to know whether the world would be a better place
>if we keep devfs, remove devfs or remove devfs even later on. I don't
>think anyone knows, which is why we're taking this little
>disable-it-and-see-who-shouts approach.
>
>
I would prefer to keep devfs around as well, but most of my embedded
systems have enough RAM to put a primitive /dev tree in tmpfs using a
linuxrc script at boot. The workarounds for the userland requirements
of udev are a little less clear to me, but I'm not sure they're
insurmountable yet for anything except the smallest embedded systems,
since Busybox appears to have some udev support available now.
I think that devfs and udev appeal to different audiences, hence I don't
think you can say that the "world will be a better place" with one or
the other. It would be nice to find a way to have the two coexist
peacefully...
Case in point. I'm going to udev reluctantly; all my embedded work
based on earlier kernels used devfs exclusively.
b.g.
--
Bill Gatliff
So what part of:
$ make oldconfig clean dep zImage
do you not understand?
bgat@billgatliff.com
next prev parent reply other threads:[~2005-06-23 2:22 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-21 6:29 [GIT PATCH] Remove devfs from 2.6.12-git Greg KH
2005-06-21 6:30 ` [PATCH] devfs: Remove devfs from the partition code Greg KH
2005-06-21 6:54 ` [GIT PATCH] Remove devfs from 2.6.12-git Andrew Morton
2005-06-21 13:50 ` Adrian Bunk
2005-06-21 15:10 ` Greg KH
2005-06-21 20:11 ` Andrew Morton
2005-06-21 20:52 ` Arjan van de Ven
2005-06-21 21:03 ` Andrew Morton
2005-06-21 21:16 ` Greg KH
2005-06-21 21:58 ` J.A. Magallon
2005-06-23 1:00 ` Mike Bell
2005-06-23 1:18 ` Andrew Morton
2005-06-23 2:13 ` Bill Gatliff [this message]
2005-06-23 4:59 ` Greg KH
2005-06-23 6:14 ` Miles Bader
2005-06-23 6:26 ` Greg KH
2005-06-23 6:36 ` Miles Bader
2005-06-23 7:03 ` Greg KH
2005-06-23 19:54 ` Kay Sievers
2005-06-23 6:34 ` Mike Bell
2005-06-23 6:37 ` Andrew Morton
2005-06-23 6:47 ` Mike Bell
2005-06-23 6:51 ` Greg KH
2005-06-23 6:38 ` Miles Bader
2005-06-23 6:28 ` Mike Bell
2005-06-23 6:48 ` Greg KH
2005-06-23 8:29 ` Mike Bell
2005-06-23 12:58 ` Theodore Ts'o
2005-06-24 8:24 ` Greg KH
2005-06-23 15:13 ` Per Liden
2005-07-18 16:36 ` Richard Gooch
2005-07-18 20:12 ` Jan Engelhardt
2005-07-18 22:29 ` Daniel Phillips
2005-07-19 2:51 ` Jim Crilly
2005-06-21 17:35 ` Carsten Otte
-- strict thread matches above, loose matches on Subject: below --
2005-06-23 4:08 David Brownell
2005-06-23 6:21 ` Miles Bader
2005-06-23 8:10 ` Russell King
2005-06-23 5:08 David Brownell
2005-06-23 5:22 ` Bill Gatliff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42BA1ADB.6090006@billgatliff.com \
--to=bgat@billgatliff.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.