[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
on i386.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 12 Nov 2005

--- linux-2.6.14-mm2-full/include/asm-i386/io.h.old	2005-11-12 01:44:38.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/io.h	2005-11-12 01:45:58.000000000 +0100
@@ -144,8 +144,14 @@
  *
  * Allow them on x86 for legacy drivers, though.
  */
-#define virt_to_bus virt_to_phys
-#define bus_to_virt phys_to_virt
+static inline unsigned long __deprecated virt_to_bus(volatile void * address)
+{
+	return __pa(address);
+}
+static inline void * __deprecated bus_to_virt(unsigned long address)
+{
+	return __va(address);
+}
 
 /*
  * readX/writeX() are used to access memory mapped devices. On some

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> on i386.
> 

Problem is, nobody's fixing these things.  There's no point in adding spam
to the kernel build unless it actually gets us some action, and I haven't
seen any evidence that it does.

Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Thu, Nov 17, 2005 at 05:50:15PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> > on i386.
> > 
> 
> Problem is, nobody's fixing these things.  There's no point in adding spam
> to the kernel build unless it actually gets us some action, and I haven't
> seen any evidence that it does.
> 
> Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.

I'm used to the fact that every single BROKEN_ON_SMP driver generates 
tons of such warnings that I don't see why these warnings should be any 
bad...

If you dislike the warnings, you could move the whole __deprecated und a 
config option.

In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
drivers that seem to have an active maintainer might get fixed.

But I'm not religious regarding this issue as long as you accept my 
-Werror-implicit-function-declaration patch...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> On Thu, Nov 17, 2005 at 05:50:15PM -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> > > on i386.
> > > 
> > 
> > Problem is, nobody's fixing these things.  There's no point in adding spam
> > to the kernel build unless it actually gets us some action, and I haven't
> > seen any evidence that it does.
> > 
> > Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.
> 
> I'm used to the fact that every single BROKEN_ON_SMP driver generates 
> tons of such warnings that I don't see why these warnings should be any 
> bad...

I frequently (daily) get patches which spit new warnings.  Sometimes
(~weekly) those warnings indicate real bugs in the patch.

I believe that the main reason for this is that the developers simply don't
notice the new warning amongst all the noise.

> If you dislike the warnings, you could move the whole __deprecated und a 
> config option.
> 
> In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
> drivers that seem to have an active maintainer might get fixed.

That would be good - but perhaps a better approach would be to send pointed
emails to the maintainer.  Or to merge lameo patches to remove
virt_to_bus() so he has to fix it for real ;)

> But I'm not religious regarding this issue as long as you accept my 
> -Werror-implicit-function-declaration patch...

Problem is, I'm the sucker who takes the brunt of that change.  It'd be
best to fix up the warnings _before_ adding the make-it-break patch.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Thu, Nov 17, 2005 at 06:20:47PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > On Thu, Nov 17, 2005 at 05:50:15PM -0800, Andrew Morton wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated 
> > > > on i386.
> > > > 
> > > 
> > > Problem is, nobody's fixing these things.  There's no point in adding spam
> > > to the kernel build unless it actually gets us some action, and I haven't
> > > seen any evidence that it does.
> > > 
> > > Stick it under CONFIG_I_AM_A_DEVELOPER_WHO_HAS_TIME_TO_FIX_STUFF.
> > 
> > I'm used to the fact that every single BROKEN_ON_SMP driver generates 
> > tons of such warnings that I don't see why these warnings should be any 
> > bad...
> 
> I frequently (daily) get patches which spit new warnings.  Sometimes
> (~weekly) those warnings indicate real bugs in the patch.
> 
> I believe that the main reason for this is that the developers simply don't
> notice the new warning amongst all the noise.

There are few areas in the kernel that spit that many warnings that you 
might not see new ones .

The developers not noticing the warnings might often be the same 
developers who send patches that don't compile...

> > If you dislike the warnings, you could move the whole __deprecated und a 
> > config option.
> > 
> > In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
> > drivers that seem to have an active maintainer might get fixed.
> 
> That would be good - but perhaps a better approach would be to send pointed
> emails to the maintainer.  Or to merge lameo patches to remove
> virt_to_bus() so he has to fix it for real ;)

In the case of virt_to_bus/bus_to_virt there are stil many places in the 
kernel using it, and several of them are well maintained.

IMHO the warnings are the best solution for getting a vast amount fixed, 
and then it's time to think about the rest.

> > But I'm not religious regarding this issue as long as you accept my 
> > -Werror-implicit-function-declaration patch...
> 
> Problem is, I'm the sucker who takes the brunt of that change.  It'd be
> best to fix up the warnings _before_ adding the make-it-break patch.

-Werror-implicit-function-declaration doesn't add new warnings, it turns 
a specific kind of warnings that can indicate nasty runtime errors into 
compile errors.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> > 
> > I believe that the main reason for this is that the developers simply don't
> > notice the new warning amongst all the noise.
> 
> There are few areas in the kernel that spit that many warnings that you 
> might not see new ones .
> 
> The developers not noticing the warnings might often be the same 
> developers who send patches that don't compile...

Some architectures generate a lot more warnings than x86.

> > > If you dislike the warnings, you could move the whole __deprecated und a 
> > > config option.
> > > 
> > > In the case of virt_to_bus/bus_to_virt I had the hope that e.g. the ATM 
> > > drivers that seem to have an active maintainer might get fixed.
> > 
> > That would be good - but perhaps a better approach would be to send pointed
> > emails to the maintainer.  Or to merge lameo patches to remove
> > virt_to_bus() so he has to fix it for real ;)
> 
> In the case of virt_to_bus/bus_to_virt there are stil many places in the 
> kernel using it, and several of them are well maintained.
> 
> IMHO the warnings are the best solution for getting a vast amount fixed, 
> and then it's time to think about the rest.

But the warnings don't *work*.  I'm *still* staring at stupid pm_register
and intermodule_foo warnings.  How long has that been?

> > > But I'm not religious regarding this issue as long as you accept my 
> > > -Werror-implicit-function-declaration patch...
> > 
> > Problem is, I'm the sucker who takes the brunt of that change.  It'd be
> > best to fix up the warnings _before_ adding the make-it-break patch.
> 
> -Werror-implicit-function-declaration doesn't add new warnings, it turns 
> a specific kind of warnings that can indicate nasty runtime errors into 
> compile errors.

I know, that's why the patch hurts so much.  As I say, we'd be better off
fixing up all the warnings we can before turning them into build errors.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Thu, Nov 17, 2005 at 06:55:29PM -0800, Andrew Morton wrote:

 > > IMHO the warnings are the best solution for getting a vast amount fixed, 
 > > and then it's time to think about the rest.
 > 
 > But the warnings don't *work*.  I'm *still* staring at stupid pm_register
 > and intermodule_foo warnings.  How long has that been?

Too long.  I think the mtd stuff won't ever get fixed until after that
function gets removed.

		Dave

[2.6 patch] build kernel/intermodule.c only when required

[Adrian Bunk]

On Thu, Nov 17, 2005 at 10:17:51PM -0500, Dave Jones wrote:
> On Thu, Nov 17, 2005 at 06:55:29PM -0800, Andrew Morton wrote:
> 
>  > > IMHO the warnings are the best solution for getting a vast amount fixed, 
>  > > and then it's time to think about the rest.
>  > 
>  > But the warnings don't *work*.  I'm *still* staring at stupid pm_register
>  > and intermodule_foo warnings.  How long has that been?
> 
> Too long.  I think the mtd stuff won't ever get fixed until after that
> function gets removed.

Let's limit the inclusion of kernel/intermodule.c to the users of these 
drivers.

> 		Dave

cu
Adrian


<--  snip  -->


Let's build kernel/intermodule.c only when required.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/mtd/chips/Kconfig   |    1 +
 drivers/mtd/devices/Kconfig |    1 +
 init/Kconfig                |    3 +++
 kernel/Makefile             |    3 ++-
 4 files changed, 7 insertions(+), 1 deletion(-)

--- linux-2.6.15-rc1-mm1-full/init/Kconfig.old	2005-11-18 03:22:53.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/init/Kconfig	2005-11-18 03:23:29.000000000 +0100
@@ -456,6 +456,9 @@
 	default !SLAB
 	bool
 
+config OBSOLETE_INTERMODULE
+	tristate
+
 menu "Loadable module support"
 
 config MODULES
--- linux-2.6.15-rc1-mm1-full/kernel/Makefile.old	2005-11-18 03:21:55.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/kernel/Makefile	2005-11-18 03:22:35.000000000 +0100
@@ -6,10 +6,11 @@
 	    exit.o itimer.o time.o softirq.o resource.o \
 	    sysctl.o capability.o ptrace.o timer.o user.o \
 	    signal.o sys.o kmod.o workqueue.o pid.o \
-	    rcupdate.o intermodule.o extable.o params.o posix-timers.o \
+	    rcupdate.o extable.o params.o posix-timers.o \
 	    kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o \
 	    ktimers.o
 
+obj-$(CONFIG_OBSOLETE_INTERMODULE) += intermodule.o
 obj-$(CONFIG_FUTEX) += futex.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
 obj-$(CONFIG_SMP) += cpu.o spinlock.o
--- linux-2.6.15-rc1-mm1-full/drivers/mtd/chips/Kconfig.old	2005-11-18 03:23:52.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/drivers/mtd/chips/Kconfig	2005-11-18 03:28:09.000000000 +0100
@@ -31,6 +31,7 @@
 
 config MTD_GEN_PROBE
 	tristate
+	select OBSOLETE_INTERMODULE
 
 config MTD_CFI_ADV_OPTIONS
 	bool "Flash chip driver advanced configuration options"
--- linux-2.6.15-rc1-mm1-full/drivers/mtd/devices/Kconfig.old	2005-11-18 03:25:17.000000000 +0100
+++ linux-2.6.15-rc1-mm1-full/drivers/mtd/devices/Kconfig	2005-11-18 03:27:46.000000000 +0100
@@ -202,6 +202,7 @@
 config MTD_DOCPROBE
 	tristate
 	select MTD_DOCECC
+	select OBSOLETE_INTERMODULE
 
 config MTD_DOCECC
 	tristate

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[David S. Miller]

From: Dave Jones <davej@redhat.com>
Date: Thu, 17 Nov 2005 22:17:51 -0500

> On Thu, Nov 17, 2005 at 06:55:29PM -0800, Andrew Morton wrote:
> 
>  > > IMHO the warnings are the best solution for getting a vast amount fixed, 
>  > > and then it's time to think about the rest.
>  > 
>  > But the warnings don't *work*.  I'm *still* staring at stupid pm_register
>  > and intermodule_foo warnings.  How long has that been?
> 
> Too long.  I think the mtd stuff won't ever get fixed until after that
> function gets removed.

That's unfortunate considering we did cure the DRM cases :-)

My only thought is that virt_to_bus() and friends are a special case
because they mean compilation failure on most non-x86 platforms.

And frankly, __deprecated serves a different purpose as far as I'm
concerned.  It let's people working on stuff outside the tree know
that "oops you shouldn't be using that interface".

The deprecated warnings are so easy to filter out, so I don't think
noise is a good argument.  I see them all the time too.

The whole DMA API we have today was added 4+ years ago specifically
to get rid of virt_to_bus() and friends.  It's been mostly successful,
but one last nudge like this deprecation marking might help get us over
the edge and finally delete the thing for good. :-)

Anyways, my 2cents.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Andrew Morton]

"David S. Miller" <davem@davemloft.net> wrote:
>
> The deprecated warnings are so easy to filter out, so I don't think
>  noise is a good argument.  I see them all the time too.

That works for you and me.  But how to train all those people who write
warny patches?

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
 > "David S. Miller" <davem@davemloft.net> wrote:
 > >
 > > The deprecated warnings are so easy to filter out, so I don't think
 > >  noise is a good argument.  I see them all the time too.
 > 
 > That works for you and me.  But how to train all those people who write
 > warny patches?

Lots of poking with pointy sticks.  And -Werror.
(Just kidding, except for the bit about the sticks).

Seriously, you've caught me out pretty quickly after I've introduced
warnings in cpufreq/agpgart, for which I'm thankful. This does put
extra pressure on you though, and you've got better things to be
doing than sending nag emails.

		Dave

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Sam Ravnborg]

On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> "David S. Miller" <davem@davemloft.net> wrote:
> >
> > The deprecated warnings are so easy to filter out, so I don't think
> >  noise is a good argument.  I see them all the time too.
> 
> That works for you and me.  But how to train all those people who write
> warny patches?

Would it work to use -Werror only on some parts of the kernel.
Thinking of teaching kbuild to recursively apply a flags to gcc.

Then we could say that kernel/ should be warning free (to a start).

	Sam

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Dave Jones]

On Sat, Nov 19, 2005 at 01:34:35AM +0100, Sam Ravnborg wrote:
 > On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
 > > "David S. Miller" <davem@davemloft.net> wrote:
 > > >
 > > > The deprecated warnings are so easy to filter out, so I don't think
 > > >  noise is a good argument.  I see them all the time too.
 > > 
 > > That works for you and me.  But how to train all those people who write
 > > warny patches?
 > 
 > Would it work to use -Werror only on some parts of the kernel.
 > Thinking of teaching kbuild to recursively apply a flags to gcc.

Only if you also add a load of gcc switches to disable some
of the more pointless warnings, and also can live with released
kernels breaking each time a new gcc gets released.

It's an uphill battle, which is why I only suggested it in
a humourous context.

		Dave

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[David S. Miller]

From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 19 Nov 2005 01:34:35 +0100

> On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > "David S. Miller" <davem@davemloft.net> wrote:
> > >
> > > The deprecated warnings are so easy to filter out, so I don't think
> > >  noise is a good argument.  I see them all the time too.
> > 
> > That works for you and me.  But how to train all those people who write
> > warny patches?
> 
> Would it work to use -Werror only on some parts of the kernel.
> Thinking of teaching kbuild to recursively apply a flags to gcc.
> 
> Then we could say that kernel/ should be warning free (to a start).

Many ports already add -Werror to the CFLAGS via their
arch/${ARCH}/* makefiles.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Fri, Nov 18, 2005 at 05:19:43PM -0800, David S. Miller wrote:
> From: Sam Ravnborg <sam@ravnborg.org>
> Date: Sat, 19 Nov 2005 01:34:35 +0100
> 
> > On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > > "David S. Miller" <davem@davemloft.net> wrote:
> > > >
> > > > The deprecated warnings are so easy to filter out, so I don't think
> > > >  noise is a good argument.  I see them all the time too.
> > > 
> > > That works for you and me.  But how to train all those people who write
> > > warny patches?
> > 
> > Would it work to use -Werror only on some parts of the kernel.
> > Thinking of teaching kbuild to recursively apply a flags to gcc.
> > 
> > Then we could say that kernel/ should be warning free (to a start).
> 
> Many ports already add -Werror to the CFLAGS via their
> arch/${ARCH}/* makefiles.

They only add it to EXTRA_CFLAGS for one specifig subdirectory.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Adrian Bunk]

On Sat, Nov 19, 2005 at 01:34:35AM +0100, Sam Ravnborg wrote:
> On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > "David S. Miller" <davem@davemloft.net> wrote:
> > >
> > > The deprecated warnings are so easy to filter out, so I don't think
> > >  noise is a good argument.  I see them all the time too.
> > 
> > That works for you and me.  But how to train all those people who write
> > warny patches?
> 
> Would it work to use -Werror only on some parts of the kernel.
> Thinking of teaching kbuild to recursively apply a flags to gcc.
> 
> Then we could say that kernel/ should be warning free (to a start).

We can do better as we do currently, but we cannever get the kernel 100% 
warning free for all supported kernel configurations and all supported 
gcc versions.

E.g. gcc emitting some "unused variable" warnings when compiling with 
CONFIG_PCI=n is quite common, and although they could all be fixed there 
will always be some warnings with unusual kernel configurations.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Sam Ravnborg]

On Sat, Nov 19, 2005 at 09:51:20PM +0100, Adrian Bunk wrote:
> On Sat, Nov 19, 2005 at 01:34:35AM +0100, Sam Ravnborg wrote:
> > On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > > "David S. Miller" <davem@davemloft.net> wrote:
> > > >
> > > > The deprecated warnings are so easy to filter out, so I don't think
> > > >  noise is a good argument.  I see them all the time too.
> > > 
> > > That works for you and me.  But how to train all those people who write
> > > warny patches?
> > 
> > Would it work to use -Werror only on some parts of the kernel.
> > Thinking of teaching kbuild to recursively apply a flags to gcc.
> > 
> > Then we could say that kernel/ should be warning free (to a start).
> 
> We can do better as we do currently, but we cannever get the kernel 100% 
> warning free for all supported kernel configurations and all supported 
> gcc versions.
> 
> E.g. gcc emitting some "unused variable" warnings when compiling with 
> CONFIG_PCI=n is quite common, and although they could all be fixed there 
> will always be some warnings with unusual kernel configurations.

I had no issue with adding more gcc flags, but this is a very valid
argument. So I will for now not do it.
>From a kbuild perspective it could be useful in other situations
to have the possibility to add a variable that was set also and only in
sub-directories. But I will not dive into it before a better reason show
up.

	Sam

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Pavel Machek]

On Sat 19-11-05 01:34:35, Sam Ravnborg wrote:
> On Thu, Nov 17, 2005 at 08:03:54PM -0800, Andrew Morton wrote:
> > "David S. Miller" <davem@davemloft.net> wrote:
> > >
> > > The deprecated warnings are so easy to filter out, so I don't think
> > >  noise is a good argument.  I see them all the time too.
> > 
> > That works for you and me.  But how to train all those people who write
> > warny patches?
> 
> Would it work to use -Werror only on some parts of the kernel.
> Thinking of teaching kbuild to recursively apply a flags to gcc.
> 
> Then we could say that kernel/ should be warning free (to a start).

Well, please don't do that. -Werror makes development very painful.

							Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[David S. Miller]

From: Pavel Machek <pavel@suse.cz>
Date: Sun, 20 Nov 2005 23:27:32 +0000

> Well, please don't do that. -Werror makes development very painful.

I've had all of arch/sparc64 in -Werror mode for more than a year,
and it's anything but painful.  It's prevented me from introducing
numerous bugs inadvertantly.

People miss warnings or flat out ignore them, if the build fails they
will have to fix it up instead before sending in their changes.

Yes, for a spot like kernel/ it's more difficult since it's
compilation is influenced by so many configuration and platform
specific stuff, but that's just too bad.  Getting it warning free is
still something we can and should do.

Saying it's too hard, so we shouldn't even try, is a self-fufilling
prophecy.  I definitely want to add -Werror to net/ very very soon.

Re: [2.6 patch] mark virt_to_bus/bus_to_virt as __deprecated on i386

[Jesper Juhl]

On 11/18/05, Andrew Morton <akpm@osdl.org> wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > virt_to_bus/bus_to_virt are long deprecated, mark them as __deprecated
> > on i386.
> >
>
> Problem is, nobody's fixing these things.  There's no point in adding spam
> to the kernel build unless it actually gets us some action, and I haven't
> seen any evidence that it does.
>
I for one was not aware that these functions were considered to be
deprecated, some log "spam" would have alerted me to that fact.

I'll take a look at fixing up some of these, just need to go dig up
some docs on what the replacements are first, so be patient...

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html