Despite repeated attempts over the last two and half years, this driver
seems somewhat persistant. Remove its deprecated status as it has
existing users who may not be in a position to migrate their apps
to O_DIRECT.
Signed-off-by: Dave Jones <[email protected]>
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 498ff31..5108619 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -41,14 +41,6 @@ Who: Pavel Machek <[email protected]>
---------------------------
-What: RAW driver (CONFIG_RAW_DRIVER)
-When: December 2005
-Why: declared obsolete since kernel 2.6.3
- O_DIRECT can be used instead
-Who: Adrian Bunk <[email protected]>
-
----------------------------
-
What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
When: June 2007
Why: Deprecated in favour of the more efficient and robust rawiso interface.
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index abcafac..1e4d688 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -993,15 +993,14 @@ config GPIO_VR41XX
depends on CPU_VR41XX
config RAW_DRIVER
- tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
+ tristate "RAW driver (/dev/raw/rawN)"
depends on BLOCK
help
- The raw driver permits block devices to be bound to /dev/raw/rawN.
- Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
+ The raw driver permits block devices to be bound to /dev/raw/rawN.
+ Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
See the raw(8) manpage for more details.
- The raw driver is deprecated and will be removed soon.
- Applications should simply open the device (eg /dev/hda1)
+ Applications should preferably open the device (eg /dev/hda1)
with the O_DIRECT flag.
config MAX_RAW_DEVS
--
http://www.codemonkey.org.uk
On May 13 2007 12:32, Dave Jones wrote:
>Despite repeated attempts over the last two and half years, this driver
>seems somewhat persistant. Remove its deprecated status as it has
>existing users who may not be in a position to migrate their apps
>to O_DIRECT.
>
>Signed-off-by: Dave Jones <[email protected]>
>
>diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
>index 498ff31..5108619 100644
>--- a/Documentation/feature-removal-schedule.txt
>+++ b/Documentation/feature-removal-schedule.txt
>@@ -41,14 +41,6 @@ Who: Pavel Machek <[email protected]>
>
> ---------------------------
>
>-What: RAW driver (CONFIG_RAW_DRIVER)
>-When: December 2005
>-Why: declared obsolete since kernel 2.6.3
>- O_DIRECT can be used instead
>-Who: Adrian Bunk <[email protected]>
>-
>----------------------------
>-
> What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
> When: June 2007
> Why: Deprecated in favour of the more efficient and robust rawiso interface.
>diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
>index abcafac..1e4d688 100644
>--- a/drivers/char/Kconfig
>+++ b/drivers/char/Kconfig
>@@ -993,15 +993,14 @@ config GPIO_VR41XX
> depends on CPU_VR41XX
>
> config RAW_DRIVER
>- tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
>+ tristate "RAW driver (/dev/raw/rawN)"
> depends on BLOCK
> help
>- The raw driver permits block devices to be bound to /dev/raw/rawN.
>- Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
>+ The raw driver permits block devices to be bound to /dev/raw/rawN.
>+ Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
> See the raw(8) manpage for more details.
>
>- The raw driver is deprecated and will be removed soon.
>- Applications should simply open the device (eg /dev/hda1)
>+ Applications should preferably open the device (eg /dev/hda1)
> with the O_DIRECT flag.
>
> config MAX_RAW_DEVS
At least keep the "it's obsolete" Kconfig description. We
don't want new users/projects to jump on /dev/raw.
Jan
--
On Sun, May 13, 2007 at 06:35:45PM +0200, Jan Engelhardt wrote:
> >- tristate "RAW driver (/dev/raw/rawN) (OBSOLETE)"
> >+ tristate "RAW driver (/dev/raw/rawN)"
> > depends on BLOCK
> > help
> >- The raw driver permits block devices to be bound to /dev/raw/rawN.
> >- Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
> >+ The raw driver permits block devices to be bound to /dev/raw/rawN.
> >+ Once bound, I/O against /dev/raw/rawN uses efficient zero-copy I/O.
> > See the raw(8) manpage for more details.
> >
> >- The raw driver is deprecated and will be removed soon.
> >- Applications should simply open the device (eg /dev/hda1)
> >+ Applications should preferably open the device (eg /dev/hda1)
> > with the O_DIRECT flag.
> >
> > config MAX_RAW_DEVS
>
> At least keep the "it's obsolete" Kconfig description. We
> don't want new users/projects to jump on /dev/raw.
That'll just lead to some janitor sending more "OMG! OBSOLETE!" cleanup
patches getting it re-added to the feature-removal.txt
If we undeprecate it, it won't be going away, so new users of it
aren't any more of a problem than they have been the last two and
a half years.
Dave
--
http://www.codemonkey.org.uk
On Sun, 13 May 2007, Jan Engelhardt wrote:
>
> On May 13 2007 12:32, Dave Jones wrote:
>
> >Despite repeated attempts over the last two and half years, this
> >driver seems somewhat persistant. Remove its deprecated status as
> >it has existing users who may not be in a position to migrate their
> >apps
>
> At least keep the "it's obsolete" Kconfig description. We don't want
> new users/projects to jump on /dev/raw.
i just *know* this is a mistake, but i'm going to take one more shot
at distinguishing between deprecated and obsolete.
as i understand it, the raw driver is *deprecated*. that is, it's
still there, it's still supported, people are still using it but its
use is *seriously* discouraged and everyone should be trying to move
off of it at their earliest possible convenience.
that is *not* the same as "obsolete" which should mean that that
feature is dead, dead, DEAD and *no one* should be using it anymore.
yes, i realize it sounds like splitting hairs, but it's this malleable
definition of "deprecated" that's causing all of this trouble in the
first place -- the fact that the raw driver is currently listed as
"obsolete" when it is, in fact, only deprecated.
in short, do *not* remove its "deprecated" status. rather, remove its
"obsolete" status and *make* it deprecated.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
In article <[email protected]> you wrote:
> in short, do *not* remove its "deprecated" status. rather, remove its
> "obsolete" status and *make* it deprecated.
it is deprecated and obsolete.
Gruss
Bernd
On Sun, 13 May 2007, Bernd Eckenfels wrote:
> In article <[email protected]> you wrote:
> > in short, do *not* remove its "deprecated" status. rather, remove its
> > "obsolete" status and *make* it deprecated.
>
> it is deprecated and obsolete.
no, it's not. and, trust me, no one on this list wants me to have to
explain all that again. :-)
rday
p.s. before we get into this again where everyone thinks they know
what they're talking about, i suggest consulting the official
definitions of those two terms as defined at
http://www.w3.org/TR/html4/conform.html:
Deprecated:
----------
"A deprecated element or attribute is one that has been outdated by
newer constructs. Deprecated elements are defined in the reference
manual in appropriate locations, but are clearly marked as deprecated.
Deprecated elements may become obsolete in future versions of HTML.
"User agents should continue to support deprecated elements for
reasons of backward compatibility.
"Definitions of elements and attributes clearly indicate which are
deprecated."
got that? deprecated means that it's been "outdated," but it's
still defined, it's still supported, it's marked as "deprecated", and
it ***may become*** obsolete in future versions. if there's a better
description of raw drivers, i don't know where you'd find it.
Obsolete:
--------
"An obsolete element or attribute is one for which there is no
guarantee of support by a user agent."
there. see the difference? why is this so difficult to grok? you
can be deprecated, or you can be obsolete. you *can't* be both. so
please stop making that argument.
p.p.s. using those definitions, deprecated features are *not*
possible candidates for removal, but obsolete features *are*. that's
why raw drivers are deprecated, not obsolete.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
> p.s. before we get into this again where everyone thinks they know
> what they're talking about, i suggest consulting the official
> definitions of those two terms as defined at
> http://www.w3.org/TR/html4/conform.html:
>
> Deprecated:
> ----------
[...]
> Obsolete:
> --------
>
> "An obsolete element or attribute is one for which there is no
> guarantee of support by a user agent."
Please quote W3C's entire definition of their notion of obsolete:
"An obsolete element or attribute is one for which there is no guarantee
of support by a user agent. Obsolete elements are no longer defined in
the specification, but are listed for historical purposes in the changes
section of the reference manual."
> there. see the difference? why is this so difficult to grok?
[...]
If you apply W3C's term "obsolete" 1:1 to kernel features, then it would
read:
"An obsolete feature is one for which there is no guarantee of support
by a randomly picked kernel release. Obsolete features are no longer
implemented in this release, but are listed for historical purposes in
Documentation/ABI/removed/."
Except that the term "obsolete" is already used differently in the
context of Linux kernel features; see Documentation/ABI/README.
Also, you say "the official definitions of those terms" were defined at
http://www.w3.org/TR/html4/conform.html. That's not quite true. What
you find there are the definitions of those terms as used in the HTML 4
specification. Nothing more.
--
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/
Robert P. J. Day wrote:
> On Sun, 13 May 2007, Bernd Eckenfels wrote:
>
>> In article <[email protected]> you wrote:
>>> in short, do *not* remove its "deprecated" status. rather, remove its
>>> "obsolete" status and *make* it deprecated.
>> it is deprecated and obsolete.
>
> no, it's not. and, trust me, no one on this list wants me to have to
> explain all that again. :-)
So why don't we simply say:
- "Users of feature A are urged to migrate to alternative B."
- "Feature C will be removed in February 2038."
Everybody understands the meaning of /that/.
--
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/
On Sun, 13 May 2007, Stefan Richter wrote:
> Except that the term "obsolete" is already used differently in the
> context of Linux kernel features; see Documentation/ABI/README.
no, it isn't. in fact, it's used in that file *exactly* the way i've
been defining it:
"obsolete/"
"This directory documents interfaces that are still remaining in the
kernel, but are marked to be removed at some later point in time.
The description of the interface will document the reason why it is
obsolete and when it can be expected to be removed. The file
Documentation/feature-removal-schedule.txt may describe some of these
interfaces, giving a schedule for when they will be removed."
note the salient points of what is considered "obsolete":
* yes, it's still in the kernel
* it may already be scheduled to be removed
* it's documented why that interface is ***obsolete*** and is
scheduled for removal
look carefully, stefan -- note what's missing from that explanation:
the word "deprecated" which, IMHO, means something quite different.
at this point, i've explained several times already what i think is
the difference between these two terms, and why i think it's an
*important* difference and how those terms should be used to guarantee
clarity.
you clearly disagree and there's absolutely nothing i can say at
this point that's going to get through to you and i'm as thoroughly
tired of trying to explain it to you as i'm sure everyone else is of
reading it. so let's just accept that any further discussion on this
topic is a waste of time. and we can leave things the way they are,
and things will continue to be mis-labelled and people will, on a
regular basis, continue to submit patches to remove things that claim
to be "obsolete" but which aren't, and this whole freakin' debate will
start all over again.
happy now?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
Robert P. J. Day wrote:
> On Sun, 13 May 2007, Stefan Richter wrote:
>
>> Except that the term "obsolete" is already used differently in the
>> context of Linux kernel features; see Documentation/ABI/README.
>
> no, it isn't. in fact, it's used in that file *exactly* the way i've
> been defining it:
I meant _differently from the term in the HTML spec_.
--
Stefan Richter
-=====-=-=== -=-= -==-=
http://arcgraph.de/sr/
Am 13.05.2007 22:10 schrieb Stefan Richter:
> So why don't we simply say:
>
> - "Users of feature A are urged to migrate to alternative B."
> - "Feature C will be removed in February 2038."
Because that's too long to add to a Kconfig tag line.
You need a terse label there.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
Tilman Schmidt wrote:
> Am 13.05.2007 22:10 schrieb Stefan Richter:
>> So why don't we simply say:
>>
>> - "Users of feature A are urged to migrate to alternative B."
>> - "Feature C will be removed in February 2038."
>
> Because that's too long to add to a Kconfig tag line.
> You need a terse label there.
Then put "DEPRECATED" there, because you deprecate the enabling of the
option.
However, actual users of such a kernel option need the full explanation
of what's wrong with the option in order to decide whether to switch it
off. The terse label alone is *insufficient*. It's insufficient even
if you develop a scheme with two or more different labels for different
flavors of deprecation. In fact, generically defined finer-grained
flavors of "deprecated" will be too fine-grained to be sensibly used in
/real/ feature removal processes.
It doesn't lead us anywhere to discuss about deprecation on an abstract
level. Discuss concrete features (like the raw driver) with the people
who used that feature --- only then you get to know how to proceed with
that feature appropriately.
--
Stefan Richter
-=====-=-=== -=-= -===-
http://arcgraph.de/sr/
Stefan Richter <stefanr <at> s5r6.in-berlin.de> writes:
> So why don't we simply say:
>
> - "Users of feature A are urged to migrate to alternative B."
> - "Feature C will be removed in February 2038."
>
> Everybody understands the meaning of /that/.
Why not just use the terms:
* outdated - as a replacement for "deprecated".
* toberemoved - as a replacement for "obsolete".
These terms are easy to understand, short, universally accepted and extremely
difficult to get wrong.
On Sun, 13 May 2007 23:01:51 +0000 (UTC)
Bob Johnston <[email protected]> wrote:
> Stefan Richter <stefanr <at> s5r6.in-berlin.de> writes:
> > So why don't we simply say:
> >
> > - "Users of feature A are urged to migrate to alternative B."
> > - "Feature C will be removed in February 2038."
> >
> > Everybody understands the meaning of /that/.
>
> Why not just use the terms:
> * outdated - as a replacement for "deprecated".
Because they don't actually mean the same thing ?
> * toberemoved - as a replacement for "obsolete".
With spaces, I'd hope.
Robert P. J. Day wrote:
> On Sun, 13 May 2007, Jan Engelhardt wrote:
>
>> On May 13 2007 12:32, Dave Jones wrote:
>>
>>> Despite repeated attempts over the last two and half years, this
>>> driver seems somewhat persistant. Remove its deprecated status as
>>> it has existing users who may not be in a position to migrate their
>>> apps
>> At least keep the "it's obsolete" Kconfig description. We don't want
>> new users/projects to jump on /dev/raw.
>
> i just *know* this is a mistake, but i'm going to take one more shot
> at distinguishing between deprecated and obsolete.
>
> as i understand it, the raw driver is *deprecated*. that is, it's
> still there, it's still supported, people are still using it but its
> use is *seriously* discouraged and everyone should be trying to move
> off of it at their earliest possible convenience.
>
> that is *not* the same as "obsolete" which should mean that that
> feature is dead, dead, DEAD and *no one* should be using it anymore.
>
> yes, i realize it sounds like splitting hairs, but it's this malleable
> definition of "deprecated" that's causing all of this trouble in the
> first place -- the fact that the raw driver is currently listed as
> "obsolete" when it is, in fact, only deprecated.
>
> in short, do *not* remove its "deprecated" status. rather, remove its
> "obsolete" status and *make* it deprecated.
>
Correct. Like the weird lady next door who fancies you, it's old, it's
ugly, but it's not likely to go away any time soon.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
Alan Cox <alan <at> lxorguk.ukuu.org.uk> writes:
> > Why not just use the terms:
> > * outdated - as a replacement for "deprecated".
>
> Because they don't actually mean the same thing ?
"superseded" would probably be a better word, perhaps lacking the negative
connotations of "deprecated"
> > * toberemoved - as a replacement for "obsolete".
>
> With spaces, I'd hope.
Sure.
I'm just trying to propose an alternative because it seems that
deprecated/obsolete causes some confusion.
On Mon, 14 May 2007, Bob Johnston wrote:
> Alan Cox <alan <at> lxorguk.ukuu.org.uk> writes:
>
> > > Why not just use the terms:
> > > * outdated - as a replacement for "deprecated".
> >
> > Because they don't actually mean the same thing ?
>
> "superseded" would probably be a better word, perhaps lacking the
> negative connotations of "deprecated"
except that you *want* the negative connotation associated with the
word "deprecated." you don't just want to say something's been
superseded. rather, you want to say that it's not only been
superseded but that you really want people to *stop using it* and move
up to the newer version; otherwise, there is no motivation to upgrade.
i'm just baffled by the resistance to the word "deprecated" since it
represents *exactly* the idea you want to get across here. its use
in software projects is well-established. why are some people so put
off by it?
> I'm just trying to propose an alternative because it seems that
> deprecated/obsolete causes some confusion.
no, it does *not* cause confusion. by now, everyone who's been
following this thread knows *exactly* what those two words are being
proposed to represent. what's happening is that they don't *like*
that proposed usage.
quite simply, there is no confusion here, there is simply annoying
obstinacy. there's a difference.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
> On Mon, 14 May 2007, Bob Johnston wrote:
> > Alan Cox <alan <at> lxorguk.ukuu.org.uk> writes:
> >
> > > > Why not just use the terms:
> > > > * outdated - as a replacement for "deprecated".
> > >
> > > Because they don't actually mean the same thing ?
> >
> > "superseded" would probably be a better word, perhaps lacking the
> > negative connotations of "deprecated"
> except that you *want* the negative connotation associated with the
> word "deprecated." you don't just want to say something's been
> superseded. rather, you want to say that it's not only been
> superseded but that you really want people to *stop using it* and move
> up to the newer version; otherwise, there is no motivation to upgrade.
> i'm just baffled by the resistance to the word "deprecated" since it
> represents *exactly* the idea you want to get across here. its use
> in software projects is well-established. why are some people so put
> off by it?
Let me give this a big AOL-style "me too". Terms such as "deprecated" and
"obsolete" have been used by programmers for as long as I can remember, and
if you don't know exactly what they mean, you probably should just learn.
A feature is "deprecated" if there is some other feature or mechanism that
is considered superior to it in all cases. It may just be more efficient, it
may avoid potential pitfalls of the deprecated mechanism.
You should avoid using a deprecated feature in new code and should try to
remove use of it from old code. The classic example of a deprecated function
is 'gets'. Deprecated features are generally kept for compatability purposes
or because standards require them. A function deprecated on one platform may
be perfectly fine on another.
You might choose to use a deprecated feature for compatability purposes. It
is not urgent to hack use of deprecated features out of existing code.
(However, you should evaluate whether the reason for deprecation creates a
problem in your code, especially if it's a security issue.)
Deprecated features can reasonably be expected to continue to work as well
as they ever have. They should not be newly-broken. If a deprecated feature
is broken in a new version, that is a regression.
A feature is "obsolete" if it no longer serves any purpose. It may be so
broken that it is no longer even usable. It might still be technically
working but not have any actual case of any significance in which you might
want to use it. Linux's Sony CDU-535 driver is obsolete (a driver for an old
CDROM drive with a specialized ISA controller that transferred data at well
less than 1X and supports only a *very* slow PIO mode).
Obsolete features are generally scheduled for removal. They are usually not
removed just on the off chance that the removal might harm someone. It may
not even be possible to test them and the last time they were tested may
have been several major releases ago. One should generally not expect
obsolete features to work.
Something obsolete may conflict with never features. For example, a driver
that breaks with hotpluggable CPUs. One contemplating using an obsolete
feature in a new design should have a damn good reason and might possibly
need to have their head examined.
The raw driver *is* deprecated. It is *not* obsolete.
DS