Re: 2.6.16-rc1-mm4

[Randy.Dunlap]

On Mon, 30 Jan 2006 00:58:53 +0100 Adrian Bunk wrote:

> On Sun, Jan 29, 2006 at 03:40:02PM -0800, Randy.Dunlap wrote:
> > On Mon, 30 Jan 2006 00:34:03 +0100 Adrian Bunk wrote:
> > 
> > > On Sun, Jan 29, 2006 at 02:45:33PM -0800, Andrew Morton wrote:
> > > >...
> > > > Changes since 2.6.16-rc1-mm3:
> > > >...
> > > > +i386-add-a-temporary-to-make-put_user-more-type-safe.patch
> > > > 
> > > >  x86 fixes/features
> > > >...
> > > 
> > > This patch generates so many "ISO C90 forbids mixed declarations and code"
> > > warnings that I start to consider Andrew's rejection of my "mark 
> > > virt_to_bus/bus_to_virt as __deprecated on i386" patch due to the 
> > > warnings it generates a personal insult...
> > 
> > I prefer to think of it as reasons why neither of them
> > should be merged.
> 
> 
> Some remarks:
> 
> 
> I forgot the smiley.

OK.  I guess I should not have replied at all then.

> If we want to get rid of a long deprecated API (as in the 
> virt_to_bus/bus_to_virt case), adding warnings could help making 
> maintainers aware of the fact that the API is deprecated.

I seriously expect that the maintainers are already aware
of that.  It's not new(s).

> In such cases the warnings are supposed to be present only temporarily 
> until the code using the deprecated API got fixed.
> 
> It might not be visible for people only using allyesconfig/allmodconfig, 
> but BROKEN_ON_SMP drivers often spit screenfuls of warnings. That's OK, 
> and most of them have been fixed during the last years.
> 
> And otherwise, we could simply remove __deprecated from the kernel.
> 
> Andrew rejected my patch to add -Werror-implicit-function-declaration to 
> the CFLAGS which helps us to avoid a certain class of nasty runtime 
> errors because it turned virt_to_bus/bus_to_virt link errors on powerpc 
> into compile errors (sic).
> 
> 
> > ~Randy
> 
> cu
> Adrian


---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/