From: Bill Gatliff <bgat@billgatliff.com>
To: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PATCH] Remove devfs from 2.6.12-git
Date: Thu, 23 Jun 2005 00:22:38 -0500 [thread overview]
Message-ID: <42BA471E.7010208@billgatliff.com> (raw)
In-Reply-To: <200506222208.58494.david-b@pacbell.net>
David:
David Brownell wrote:
>The downside of "disable-and-remove-later" is that it becomes
>too easy to just re-enable the Kconfig stuff rather than just
>fixing the userspace bugs. Expecting userspace to change at
>any point before it absolutely _must_ tends to be a formula
>for userspace never changing, sadly enough.
>
>If 2.6.13 doesn't remove devfs, when will it really go away?
>
>
Good point. I've come this far somewhat reluctantly, but can see that
udev is a better long-term solution. Once devfs is gone, it's easier
for me to justify doing the work to go fully over to udev (GregKH, can
you post a link or two to those "packages" you refer to?).
And also, once devfs is gone it's an easier economic decision for my
customers, too: either they move ahead and get whatever new features
that non-devfs kernels offer, or they do the work to keep the current
stuff in the state they want it. It's their call, I (sometimes) get
paid either way...
And it isn't like just my customers would be in this situation, everyone
will have to face it. So it's "fair" for everyone.
So, I guess I'm into the "say goodbye to devfs" camp now. In case
anyone asks, that is. :^)
b.g.
--
Bill Gatliff
Build a man a fire, and he's warm for the rest of the night.
Set a man on fire, and he's warm for the rest of his life.
-- Anonymous
bgat@billgatliff.com
next prev parent reply other threads:[~2005-06-23 5:23 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-23 5:08 [GIT PATCH] Remove devfs from 2.6.12-git David Brownell
2005-06-23 5:22 ` Bill Gatliff [this message]
-- 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-21 6:29 Greg KH
2005-06-21 6:54 ` 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
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
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=42BA471E.7010208@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.