From: "R. J. Wysocki" <rjwysocki@sisk.pl>
To: linux-kernel@vger.kernel.org
Subject: [RFC]: CONFIG_UNSUPPORTED (was: Re: [PATCH] delete devfs)
Date: Fri, 23 Jul 2004 21:06:40 +0200 [thread overview]
Message-ID: <200407232106.41065.rjwysocki@sisk.pl> (raw)
In-Reply-To: <20040722091335.A17187@home.com>
Hi listmembers,
I'm not a kernel developer, but recently I've been testing many development
(ie. -mm and -rc) kernels and I run a network containing quite a lot of Linux
boxes, so I'm involved (a little) in the kernel development or at least I'm
affected by it to some extent. Anyway, I have an idea that I think you may
find interesting.
1. Background
There apparently is some code in the kernel tree that is buggy and not
maintained by anyone. The recent attempts to remove some parts of it (devfs,
cryptoloop) have been opposed, as it turns out that they are still in use.
OTOH, because this code is present in the mainline kernel, the users of the
kernel can expect that the code will be supported by kernel developers, which
is not correct. Therefore the code should be removed from the kernel, so
that it's not used by any new users who may expect it to be supported (there
are many other reasons for removing it, but this one alone is sufficient,
IMHO).
Having said that, it is not very nice to pull rugs from under people in
general, so before the unmaintained code is removed from the kernel, its
current users should be given some time to accommodate to the upcoming
changes. Therefore the unsupported code should be made clearly
distinguishable from the rest of the kernel code and documented as such, in
order to indicate to the users that it may be removed at any time.
2. Proposal
I propose to introduce a new configuration option CONFIG_UNSUPPORTED, such
that if it is not set, the unmaintained/unsupported code will not be compiled
into the kernel. Moreover,
* IMO the option should not be set by default, which would require a user
action to include the unsupported code into the kernel,
* IMO the option should be documented as to indicate that the code marked with
the help of it is not supported by kernel developers and may be removed from
the kernel at any time without notification.
I think that this would be fair enough wrt. users, who would be able to learn
that the code is not maintained and may be removed at any time without
notification, and they should not expect to get any support ftom the kernel
developers wrt. this code, and it's generally not a good idea to file any bug
reports regarding this code, because the bugs in it will not be fixed anyway.
OTOH, it would give the kernel developers a means to mark
unsupported/unmaintained code as such in advance, without harming any users
in the short run.
Yours,
rjw
--
Rafael J. Wysocki
[tel. (+48) 605 053 693]
----------------------------
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
-- Richard P. Feynman
next prev parent reply other threads:[~2004-07-23 18:57 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-21 14:15 [PATCH] delete devfs Greg KH
2004-07-21 14:26 ` Oliver Neukum
2004-07-21 14:35 ` Lars Marowsky-Bree
2004-07-21 14:52 ` Greg KH
2004-07-21 21:19 ` Jesse Stockall
2004-07-21 21:27 ` Greg KH
2004-07-21 21:53 ` Jesse Stockall
2004-07-21 22:05 ` Greg KH
2004-07-21 22:17 ` Jesse Stockall
2004-07-21 22:47 ` Oliver Neukum
2004-07-22 6:49 ` Greg KH
2004-07-22 9:55 ` Oliver Neukum
2004-07-22 10:08 ` Paolo Ciarrocchi
2004-07-22 16:13 ` Matt Porter
2004-07-23 19:06 ` R. J. Wysocki [this message]
2004-07-23 20:04 ` [RFC]: CONFIG_UNSUPPORTED (was: Re: [PATCH] delete devfs) Adrian Bunk
2004-07-23 21:17 ` Russell King
2004-07-23 21:22 ` R. J. Wysocki
2004-07-23 23:35 ` Sam Ravnborg
2004-07-23 22:01 ` [RFC]: CONFIG_UNSUPPORTED Stephen Wille Padnos
2004-07-22 1:08 ` [PATCH] delete devfs Grzegorz Jaśkiewicz
2004-07-22 1:48 ` Mike Snitzer
2004-07-21 22:02 ` Adrian Bunk
2004-07-21 22:07 ` Greg KH
2004-07-21 22:14 ` David Weinehall
2004-07-21 22:31 ` Brian Gerst
2004-07-21 23:11 ` New dev model (was [PATCH] delete devfs) Jonathan Corbet
2004-07-21 23:52 ` Adrian Bunk
2004-07-22 9:55 ` Andrew Morton
2004-07-22 7:04 ` Greg KH
2004-07-22 10:19 ` Andrew Morton
2004-07-22 12:55 ` Josh Boyer
2004-07-22 11:32 ` Giacomo A. Catenazzi
2004-07-22 19:12 ` Greg KH
2004-07-22 19:33 ` Adrian Bunk
2004-07-22 22:28 ` Paul Jackson
2004-07-22 23:25 ` Adrian Bunk
2004-07-23 2:22 ` Tim Wright
2004-07-23 6:31 ` Ville Herva
2004-07-23 21:04 ` Valdis.Kletnieks
2004-07-23 21:08 ` Ville Herva
2004-07-25 11:59 ` Jan Knutar
2004-07-25 18:53 ` Jesper Juhl
2004-07-23 8:16 ` szonyi calin
2004-07-23 12:21 ` Jonathan Corbet
2004-07-23 19:59 ` Adrian Bunk
2004-07-24 14:24 ` Marcelo Tosatti
2004-07-23 14:54 ` Geert Uytterhoeven
2004-07-23 15:50 ` szonyi calin
2004-07-27 22:18 ` Bill Davidsen
2004-07-28 21:25 ` Krzysztof Halasa
2004-08-02 18:48 ` Bill Davidsen
2004-08-03 22:07 ` Krzysztof Halasa
2004-07-24 16:21 ` Ragnar Hojland Espinosa
2004-07-27 22:12 ` Bill Davidsen
2004-07-28 7:24 ` Paul Jackson
2004-07-22 23:01 ` Andrew Morton
2004-07-22 20:18 ` Adrian Bunk
2004-07-22 20:28 ` Kevin Fox
2004-07-23 20:09 ` Adrian Bunk
2004-07-22 21:01 ` Martin Schlemmer
2004-07-23 0:39 ` Jason Cooper
2004-07-23 20:57 ` Timothy Miller
2004-07-25 13:30 ` Adrian Bunk
2004-07-26 1:38 ` Ben Hoskings
2004-07-26 2:12 ` Bernd Eckenfels
2004-07-28 6:25 ` Ben Hoskings
2004-07-28 21:23 ` Krzysztof Halasa
2004-08-04 21:53 ` Bernd Eckenfels
2004-07-28 21:22 ` Krzysztof Halasa
2004-07-29 12:25 ` Adrian Bunk
2004-07-22 1:33 ` [PATCH] delete devfs Mike Snitzer
2004-07-21 23:26 ` R. J. Wysocki
2004-07-21 22:11 ` Francois Romieu
2004-07-21 22:40 ` Adrian Bunk
2004-07-21 23:15 ` Francois Romieu
2004-07-22 8:23 ` sam
2004-07-22 10:24 ` Gene Heskett
2004-07-22 10:58 ` Nick Piggin
2004-07-22 21:06 ` sam
2004-07-23 0:21 ` Gene Heskett
2004-07-22 22:19 ` Paul Jakma
2004-07-22 19:22 ` Martin Schlemmer
2004-07-22 17:56 ` Deepak Saxena
2004-07-21 14:52 ` Geert Uytterhoeven
2004-07-21 14:41 ` Matthew Garrett
2004-07-21 18:25 ` Greg KH
2004-07-21 19:55 ` Matthew Garrett
2004-07-21 19:34 ` Chris Wedgwood
2004-07-21 21:13 ` Ben Collins
2004-07-21 22:20 ` Wichert Akkerman
2004-07-22 19:44 ` Martin Schlemmer
2004-07-21 15:49 ` Kasper Sandberg
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=200407232106.41065.rjwysocki@sisk.pl \
--to=rjwysocki@sisk.pl \
--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.