[2.6 patch] unexport do_settimeofday

[2.6 patch] unexport do_settimeofday

[Adrian Bunk]

I haven't found any possible modular usage of do_settimeofday in the 
kernel.

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

---

This patch was already sent on:
- 20 Jan 2005

 arch/alpha/kernel/time.c     |    2 --
 arch/arm/kernel/time.c       |    2 --
 arch/arm26/kernel/time.c     |    2 --
 arch/cris/kernel/time.c      |    2 --
 arch/h8300/kernel/time.c     |    2 --
 arch/i386/kernel/time.c      |    2 --
 arch/m32r/kernel/time.c      |    2 --
 arch/m68k/kernel/time.c      |    2 --
 arch/m68knommu/kernel/time.c |    1 -
 arch/mips/dec/time.c         |    2 --
 arch/mips/kernel/time.c      |    2 --
 arch/parisc/kernel/time.c    |    1 -
 arch/ppc/kernel/time.c       |    2 --
 arch/ppc64/kernel/time.c     |    2 --
 arch/s390/kernel/time.c      |    2 --
 arch/sh/kernel/time.c        |    2 --
 arch/sparc/kernel/time.c     |    2 --
 arch/um/kernel/ksyms.c       |    1 -
 arch/v850/kernel/time.c      |    2 --
 arch/x86_64/kernel/time.c    |    2 --
 20 files changed, 37 deletions(-)

--- linux-2.6.11-rc1-mm2-full/arch/i386/kernel/time.c.old	2005-01-20 18:52:12.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/i386/kernel/time.c	2005-01-20 18:52:27.000000000 +0100
@@ -169,8 +169,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 static int set_rtc_mmss(unsigned long nowtime)
 {
 	int retval;
--- linux-2.6.11-rc1-mm2-full/arch/arm/kernel/time.c.old	2005-01-20 18:52:46.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/arm/kernel/time.c	2005-01-20 18:52:51.000000000 +0100
@@ -301,8 +301,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 /**
  * save_time_delta - Save the offset between system time and RTC time
  * @delta: pointer to timespec to store delta
--- linux-2.6.11-rc1-mm2-full/arch/sparc/kernel/time.c.old	2005-01-20 18:52:59.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/sparc/kernel/time.c	2005-01-20 18:53:03.000000000 +0100
@@ -530,8 +530,6 @@
 	return ret;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 static int sbus_do_settimeofday(struct timespec *tv)
 {
 	time_t wtm_sec, sec = tv->tv_sec;
--- linux-2.6.11-rc1-mm2-full/arch/ppc/kernel/time.c.old	2005-01-20 18:53:11.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/ppc/kernel/time.c	2005-01-20 18:53:15.000000000 +0100
@@ -285,8 +285,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 /* This function is only called on the boot processor */
 void __init time_init(void)
 {
--- linux-2.6.11-rc1-mm2-full/arch/mips/dec/time.c.old	2005-01-20 18:53:21.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/mips/dec/time.c	2005-01-20 18:53:25.000000000 +0100
@@ -189,8 +189,6 @@
 	CMOS_WRITE(RTC_REF_CLCK_32KHZ | (16 - LOG_2_HZ), RTC_REG_A);
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 void __init dec_timer_setup(struct irqaction *irq)
 {
 	setup_irq(dec_interrupt[DEC_IRQ_RTC], irq);
--- linux-2.6.11-rc1-mm2-full/arch/mips/kernel/time.c.old	2005-01-20 18:53:32.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/mips/kernel/time.c	2005-01-20 18:53:36.000000000 +0100
@@ -234,8 +234,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 /*
  * Gettimeoffset routines.  These routines returns the time duration
  * since last timer interrupt in usecs.
--- linux-2.6.11-rc1-mm2-full/arch/m68knommu/kernel/time.c.old	2005-01-20 18:53:43.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/m68knommu/kernel/time.c	2005-01-20 18:53:47.000000000 +0100
@@ -195,4 +195,3 @@
 	return (unsigned long long)jiffies * (1000000000 / HZ);
 }
 
-EXPORT_SYMBOL(do_settimeofday);
--- linux-2.6.11-rc1-mm2-full/arch/sh/kernel/time.c.old	2005-01-20 18:53:54.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/sh/kernel/time.c	2005-01-20 18:53:58.000000000 +0100
@@ -254,8 +254,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 /* last time the RTC clock got updated */
 static long last_rtc_update;
 
--- linux-2.6.11-rc1-mm2-full/arch/cris/kernel/time.c.old	2005-01-20 18:54:05.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/cris/kernel/time.c	2005-01-20 18:54:11.000000000 +0100
@@ -122,8 +122,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 
 /*
  * BUG: This routine does not handle hour overflow properly; it just
--- linux-2.6.11-rc1-mm2-full/arch/arm26/kernel/time.c.old	2005-01-20 18:54:18.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/arm26/kernel/time.c	2005-01-20 18:54:22.000000000 +0100
@@ -198,8 +198,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 static irqreturn_t timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
 {
         do_timer(regs);
--- linux-2.6.11-rc1-mm2-full/arch/m68k/kernel/time.c.old	2005-01-20 18:54:29.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/m68k/kernel/time.c	2005-01-20 18:54:32.000000000 +0100
@@ -175,8 +175,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 /*
  * Scheduler clock - returns current time in ns units.
  */
--- linux-2.6.11-rc1-mm2-full/arch/alpha/kernel/time.c.old	2005-01-20 18:54:44.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/alpha/kernel/time.c	2005-01-20 18:54:48.000000000 +0100
@@ -512,8 +512,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 
 /*
  * In order to set the CMOS clock precisely, set_rtc_mmss has to be
--- linux-2.6.11-rc1-mm2-full/arch/ppc64/kernel/time.c.old	2005-01-20 18:54:56.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/ppc64/kernel/time.c	2005-01-20 18:54:59.000000000 +0100
@@ -424,8 +424,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 void __init time_init(void)
 {
 	/* This function is only called on the boot processor */
--- linux-2.6.11-rc1-mm2-full/arch/um/kernel/ksyms.c.old	2005-01-20 18:55:07.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/um/kernel/ksyms.c	2005-01-20 18:55:11.000000000 +0100
@@ -95,7 +95,6 @@
 EXPORT_SYMBOL(dump_thread);
 
 EXPORT_SYMBOL(do_gettimeofday);
-EXPORT_SYMBOL(do_settimeofday);
 
 /* This is here because UML expands open to sys_open, not to a system
  * call instruction.
--- linux-2.6.11-rc1-mm2-full/arch/parisc/kernel/time.c.old	2005-01-20 18:55:19.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/parisc/kernel/time.c	2005-01-20 18:55:23.000000000 +0100
@@ -197,7 +197,6 @@
 	clock_was_set();
 	return 0;
 }
-EXPORT_SYMBOL(do_settimeofday);
 
 /*
  * XXX: We can do better than this.
--- linux-2.6.11-rc1-mm2-full/arch/h8300/kernel/time.c.old	2005-01-20 18:55:33.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/h8300/kernel/time.c	2005-01-20 18:55:37.000000000 +0100
@@ -125,8 +125,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 unsigned long long sched_clock(void)
 {
 	return (unsigned long long)jiffies * (1000000000 / HZ);
--- linux-2.6.11-rc1-mm2-full/arch/m32r/kernel/time.c.old	2005-01-20 18:55:46.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/m32r/kernel/time.c	2005-01-20 18:55:50.000000000 +0100
@@ -181,8 +181,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 /*
  * In order to set the CMOS clock precisely, set_rtc_mmss has to be
  * called 500 ms after the second nowtime has started, because when
--- linux-2.6.11-rc1-mm2-full/arch/x86_64/kernel/time.c.old	2005-01-20 18:55:59.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/x86_64/kernel/time.c	2005-01-20 18:56:02.000000000 +0100
@@ -179,8 +179,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 unsigned long profile_pc(struct pt_regs *regs)
 {
 	unsigned long pc = instruction_pointer(regs);
--- linux-2.6.11-rc1-mm2-full/arch/s390/kernel/time.c.old	2005-01-20 18:56:11.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/s390/kernel/time.c	2005-01-20 18:56:15.000000000 +0100
@@ -148,8 +148,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 
 #ifdef CONFIG_PROFILING
 #define s390_do_profile(regs)	profile_tick(CPU_PROFILING, regs)
--- linux-2.6.11-rc1-mm2-full/arch/v850/kernel/time.c.old	2005-01-20 18:56:22.000000000 +0100
+++ linux-2.6.11-rc1-mm2-full/arch/v850/kernel/time.c	2005-01-20 18:56:26.000000000 +0100
@@ -179,8 +179,6 @@
 	return 0;
 }
 
-EXPORT_SYMBOL(do_settimeofday);
-
 static int timer_dev_id;
 static struct irqaction timer_irqaction = {
 	timer_interrupt,

Re: [2.6 patch] unexport do_settimeofday

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> 
>  I haven't found any possible modular usage of do_settimeofday in the 
>  kernel.

Please,

- Add deprecated_if_module

- Use it for do_settimeofday()

- Add do_settimeofday to Documentation/feature-removal-schedule.txt

Re: [2.6 patch] unexport do_settimeofday

[Arjan van de Ven]

On Thu, 2005-02-24 at 21:24 -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > 
> >  I haven't found any possible modular usage of do_settimeofday in the 
> >  kernel.
> 
> Please,
> 
> - Add deprecated_if_module
> 
> - Use it for do_settimeofday()
> 
> - Add do_settimeofday to Documentation/feature-removal-schedule.txt
> -

for _set_ time of day? I really can't imagine anyone messing with that.
_get_... sure. but set???

Re: [2.6 patch] unexport do_settimeofday

[Andrew Morton]

Arjan van de Ven <arjan@infradead.org> wrote:
>
> On Thu, 2005-02-24 at 21:24 -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > 
> > >  I haven't found any possible modular usage of do_settimeofday in the 
> > >  kernel.
> > 
> > Please,
> > 
> > - Add deprecated_if_module
> > 
> > - Use it for do_settimeofday()
> > 
> > - Add do_settimeofday to Documentation/feature-removal-schedule.txt
> > -
> 
> for _set_ time of day? I really can't imagine anyone messing with that.
> _get_... sure. but set???

Sure.  But there must have been a reason to export it in the first place.

I don't see much point in playing these games.  Deprecate it, pull it out
next year, done.

Re: [2.6 patch] unexport do_settimeofday

[Bartlomiej Zolnierkiewicz]

On Fri, 25 Feb 2005 00:28:04 -0800, Andrew Morton <akpm@osdl.org> wrote:
> Arjan van de Ven <arjan@infradead.org> wrote:
> >
> > On Thu, 2005-02-24 at 21:24 -0800, Andrew Morton wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >
> > > >
> > > >  I haven't found any possible modular usage of do_settimeofday in the
> > > >  kernel.
> > >
> > > Please,
> > >
> > > - Add deprecated_if_module
> > >
> > > - Use it for do_settimeofday()
> > >
> > > - Add do_settimeofday to Documentation/feature-removal-schedule.txt
> > > -
> >
> > for _set_ time of day? I really can't imagine anyone messing with that.
> > _get_... sure. but set???
> 
> Sure.  But there must have been a reason to export it in the first place.

sloppy coding?

Re: [2.6 patch] unexport do_settimeofday

[Andreas Dilger]

On Feb 25, 2005  09:47 +0100, Bartlomiej Zolnierkiewicz wrote:
> On Fri, 25 Feb 2005 00:28:04 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >  I haven't found any possible modular usage of do_settimeofday in the
> > >  kernel.
> > 
> > Sure.  But there must have been a reason to export it in the first place.
> 
> sloppy coding?

Who knows?  Maybe someone developed a kernel module that interfaces to an
unusual clock chip on their motherboard.  IMHO, all of this "_I_ don't
see any use for it, lets get rid of it because it's not useful" changing
is just a source of grief for anyone that doesn't have their code in
the kernel.

Cheers, Andreas
--
Andreas Dilger

Re: [2.6 patch] unexport do_settimeofday

[Arjan van de Ven]

On Fri, 2005-02-25 at 02:26 -0700, Andreas Dilger wrote:
> On Feb 25, 2005  09:47 +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Fri, 25 Feb 2005 00:28:04 -0800, Andrew Morton <akpm@osdl.org> wrote:
> > > Adrian Bunk <bunk@stusta.de> wrote:
> > > >  I haven't found any possible modular usage of do_settimeofday in the
> > > >  kernel.
> > > 
> > > Sure.  But there must have been a reason to export it in the first place.
> > 
> > sloppy coding?
> 
> Who knows?  Maybe someone developed a kernel module that interfaces to an
> unusual clock chip on their motherboard.  IMHO, all of this "_I_ don't
> see any use for it, lets get rid of it because it's not useful" changing
> is just a source of grief for anyone that doesn't have their code in
> the kernel.

actually exports cause kernels to be bigger. Some of these exports
aren't even used in the kernel entirely, others cause the kernel to be
bigger just by being non-static and having the symbol structures there.
A lot of them are "you really shouldn't" APIs.

By your argument, why bother with exports at all?

Re: [2.6 patch] unexport do_settimeofday

[Andrew Morton]

Arjan van de Ven <arjan@infradead.org> wrote:
>
> actually exports cause kernels to be bigger. Some of these exports
> aren't even used in the kernel entirely, others cause the kernel to be
> bigger just by being non-static and having the symbol structures there.

Yup.  IOW, this problem is so vanishingly teensy-weensy as to be almost not
a problem at all.  So we can wait 6-12 months before fixing it.

> A lot of them are "you really shouldn't" APIs.

Sure.  That's why we should remove the export.

Re: [2.6 patch] unexport do_settimeofday

[Christoph Hellwig]

On Fri, Feb 25, 2005 at 12:28:04AM -0800, Andrew Morton wrote:
> > for _set_ time of day? I really can't imagine anyone messing with that.
> > _get_... sure. but set???
> 
> Sure.  But there must have been a reason to export it in the first place.

NO.  Speaking from experience there's tons of totally pointless exports.

> I don't see much point in playing these games.  Deprecate it, pull it out
> next year, done.

Sorry, but without a development tree we don't want to play these deprecation
forever games.  If you want a longer warning period open 2.7 now that we
can work ahead there and leave 2.6 alone.  But restricting all kinds of
totally sane things from going in just doesn't work out.

Re: [2.6 patch] unexport do_settimeofday

[Adrian Bunk]

On Thu, Feb 24, 2005 at 09:24:48PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > 
> >  I haven't found any possible modular usage of do_settimeofday in the 
> >  kernel.
> 
> Please,
> 
> - Add deprecated_if_module
>...

What's the correct header file for __deprecated_if_module ?
module.h ?

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] unexport do_settimeofday

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> On Thu, Feb 24, 2005 at 09:24:48PM -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > 
> > >  I haven't found any possible modular usage of do_settimeofday in the 
> > >  kernel.
> > 
> > Please,
> > 
> > - Add deprecated_if_module
> >...
> 
> What's the correct header file for __deprecated_if_module ?

Actually, __deprecated_in_modules would be a better name.

> module.h ?

compiler.h, I guess.

--- 25/include/linux/compiler.h~a	2005-02-25 13:53:32.000000000 -0800
+++ 25-akpm/include/linux/compiler.h	2005-02-25 13:54:45.000000000 -0800
@@ -86,6 +86,12 @@ extern void __chk_io_ptr(void __iomem *)
 # define __deprecated		/* unimplemented */
 #endif
 
+#ifdef MODULE
+#define __deprecated_in_modules __deprecated
+#else
+#define __deprecated_in_modules /* OK in non-modular code */
+#endif
+
 #ifndef __must_check
 #define __must_check
 #endif
_

Re: [2.6 patch] unexport do_settimeofday

[Adrian Bunk]

On Fri, Feb 25, 2005 at 01:55:04PM -0800, Andrew Morton wrote:
>...
> --- 25/include/linux/compiler.h~a	2005-02-25 13:53:32.000000000 -0800
> +++ 25-akpm/include/linux/compiler.h	2005-02-25 13:54:45.000000000 -0800
> @@ -86,6 +86,12 @@ extern void __chk_io_ptr(void __iomem *)
>  # define __deprecated		/* unimplemented */
>  #endif
>  
> +#ifdef MODULE
> +#define __deprecated_in_modules __deprecated
> +#else
> +#define __deprecated_in_modules /* OK in non-modular code */
> +#endif
> +
>...

Looks good.


One more question:

You get a false positive if the file containing the symbol is itself a 
module.

Is there any way to solve this without additional #define's and #ifdef's 
for each symbol?


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] unexport do_settimeofday

[Andrew Morton]

Adrian Bunk <bunk@stusta.de> wrote:
>
> > +#ifdef MODULE
> > +#define __deprecated_in_modules __deprecated
> > +#else
> > +#define __deprecated_in_modules /* OK in non-modular code */
> > +#endif
> > +
> >...
> 
> Looks good.
> 
> 
> One more question:
> 
> You get a false positive if the file containing the symbol is itself a 
> module.

I don't understand what you mean.

You mean that a module is doing an EXPORT_SYMBOL of a symbol which is on
death row?

If so: err, not sure.  I guess we could just live with the warning.

> Is there any way to solve this without additional #define's and #ifdef's 
> for each symbol?

Not that I can think of.

Re: [2.6 patch] unexport do_settimeofday

[Arjan van de Ven]

On Fri, 2005-02-25 at 15:20 -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > +#ifdef MODULE
> > > +#define __deprecated_in_modules __deprecated
> > > +#else
> > > +#define __deprecated_in_modules /* OK in non-modular code */
> > > +#endif
> > > +
> > >...
> > 
> > Looks good.
> > 
> > 
> > One more question:
> > 
> > You get a false positive if the file containing the symbol is itself a 
> > module.
> 
> I don't understand what you mean.
> 
> You mean that a module is doing an EXPORT_SYMBOL of a symbol which is on
> death row?
> 
> If so: err, not sure.  I guess we could just live with the warning.

also those should be rare; it's certainly not a "core" export that 3rd
party stuff depends on but most of the time just accidentally exported
(by people who thought that they needed EXPORT_SYMBOL to glue two .c
files into the same one .o module)

Re: [2.6 patch] unexport do_settimeofday

[Adrian Bunk]

On Sat, Feb 26, 2005 at 11:01:24AM +0100, Arjan van de Ven wrote:
> On Fri, 2005-02-25 at 15:20 -0800, Andrew Morton wrote:
> > Adrian Bunk <bunk@stusta.de> wrote:
> > > 
> > > You get a false positive if the file containing the symbol is itself a 
> > > module.
> > 
> > I don't understand what you mean.
> > 
> > You mean that a module is doing an EXPORT_SYMBOL of a symbol which is on
> > death row?
> > 
> > If so: err, not sure.  I guess we could just live with the warning.
> 
> also those should be rare; it's certainly not a "core" export that 3rd
> party stuff depends on but most of the time just accidentally exported
> (by people who thought that they needed EXPORT_SYMBOL to glue two .c
> files into the same one .o module)

Some subsystems (e.g. PCMCIA, USB, ALSA, IDE, Firewire, ISDN, I2C, IPv6, 
SCSI) can be built completely modular and will therefore experience this 
issue if any symbol in them is __deprecated_in_modules.

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] unexport do_settimeofday

[Adrian Bunk]

On Fri, Feb 25, 2005 at 03:20:09PM -0800, Andrew Morton wrote:
> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > +#ifdef MODULE
> > > +#define __deprecated_in_modules __deprecated
> > > +#else
> > > +#define __deprecated_in_modules /* OK in non-modular code */
> > > +#endif
> > > +
> > >...
> > 
> > Looks good.
> > 
> > 
> > One more question:
> > 
> > You get a false positive if the file containing the symbol is itself a 
> > module.
> 
> I don't understand what you mean.
> 
> You mean that a module is doing an EXPORT_SYMBOL of a symbol which is on
> death row?

Yes.

> If so: err, not sure.  I guess we could just live with the warning.
>...

OK.

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

[2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[Adrian Bunk]

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

--- linux-2.6.11-rc4-mm1-full/Documentation/feature-removal-schedule.txt.old	2005-02-26 12:24:43.000000000 +0100
+++ linux-2.6.11-rc4-mm1-full/Documentation/feature-removal-schedule.txt	2005-02-26 12:27:18.000000000 +0100
@@ -32,3 +32,10 @@
 	/sys/devices/system/cpu/cpu%n/cpufreq/.
 Who:	Dominik Brodowski <linux@brodo.de>
 
+---------------------------
+
+What:	EXPORT_SYMBOL(do_settimeofday)
+When:	26 Aug 2005
+Files:	arch/*/kernel/time.c
+Why:	not used in the kernel
+Who:	Adrian Bunk <bunk@stusta.de>
--- linux-2.6.11-rc4-mm1-full/include/linux/time.h.old	2005-02-26 12:24:03.000000000 +0100
+++ linux-2.6.11-rc4-mm1-full/include/linux/time.h	2005-02-26 12:24:31.000000000 +0100
@@ -93,7 +93,7 @@
 #define CURRENT_TIME_SEC ((struct timespec) { xtime.tv_sec, 0 })
 
 extern void do_gettimeofday(struct timeval *tv);
-extern int do_settimeofday(struct timespec *tv);
+extern int __deprecated_in_modules do_settimeofday(struct timespec *tv);
 extern int do_sys_settimeofday(struct timespec *tv, struct timezone *tz);
 extern void clock_was_set(void); // call when ever the clock is set
 extern int do_posix_clock_monotonic_gettime(struct timespec *tp);

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20050226133337.GK3311@stusta.de> (at Sat, 26 Feb 2005 14:33:37 +0100), Adrian Bunk <bunk@stusta.de> says:


> +
> +What:	EXPORT_SYMBOL(do_settimeofday)
> +When:	26 Aug 2005
                   ~~~ Feb?
> +Files:	arch/*/kernel/time.c
> +Why:	not used in the kernel
> +Who:	Adrian Bunk <bunk@stusta.de>

--yoshfuji

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20050226.223742.103439510.yoshfuji@linux-ipv6.org> (at Sat, 26 Feb 2005 22:37:42 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:

> In article <20050226133337.GK3311@stusta.de> (at Sat, 26 Feb 2005 14:33:37 +0100), Adrian Bunk <bunk@stusta.de> says:
> 
> 
> > +
> > +What:	EXPORT_SYMBOL(do_settimeofday)
> > +When:	26 Aug 2005
>                    ~~~ Feb?
> > +Files:	arch/*/kernel/time.c
> > +Why:	not used in the kernel
> > +Who:	Adrian Bunk <bunk@stusta.de>

oops, I was wrong. This is schedule. sorry.

--yoshfuji

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[Russell King]

On Sat, Feb 26, 2005 at 02:33:37PM +0100, Adrian Bunk wrote:
> Signed-off-by: Adrian Bunk <bunk@stusta.de>

Please don't deprecate this symbol.  ARM has a large variety of RTC
implementations, some of which reside in I2C modules which are yet
to be merged.

Firstly, these aren't accessible until the i2c subsystem has been
initialised.  Secondly, i2c is modular, so this function must be
accessible from a module in order for the system time/date to be
initialised from the RTC with a modular build.

(It can be argued that you wouldn't want to build such a thing as a
module in the first place, in which case removing the export would
of course be fine.  However, we can't sanely force I2C to be either
always builtin, and placing this expectation on people will eventually
lead other janitors to complain that the symbol is used by modules but
isn't exported.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[Adrian Bunk]

On Sat, Feb 26, 2005 at 02:46:35PM +0000, Russell King wrote:
> On Sat, Feb 26, 2005 at 02:33:37PM +0100, Adrian Bunk wrote:
> 
> Please don't deprecate this symbol.  ARM has a large variety of RTC
> implementations, some of which reside in I2C modules which are yet
> to be merged.
> 
> Firstly, these aren't accessible until the i2c subsystem has been
> initialised.  Secondly, i2c is modular, so this function must be
> accessible from a module in order for the system time/date to be
> initialised from the RTC with a modular build.
> 
> (It can be argued that you wouldn't want to build such a thing as a
> module in the first place, in which case removing the export would
> of course be fine.  However, we can't sanely force I2C to be either
> always builtin, and placing this expectation on people will eventually
> lead other janitors to complain that the symbol is used by modules but
> isn't exported.)

I saw drivers/acorn/char/i2c.c, but this file is always built statically 
on ARCH_ACORN without any dependency between ARCH_ACORN and I2C.
This is buggy.

Why can't such drivers select I2C and other required I2C_* variables?

Appropriate depends or selects are required in any case.
If you plan to make drivers like drivers/acorn/char/i2c.c modular, my 
patch is void.

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] deprecate EXPORT_SYMBOL(do_settimeofday)

[Russell King]

On Sat, Feb 26, 2005 at 05:23:41PM +0100, Adrian Bunk wrote:
> On Sat, Feb 26, 2005 at 02:46:35PM +0000, Russell King wrote:
> > On Sat, Feb 26, 2005 at 02:33:37PM +0100, Adrian Bunk wrote:
> > 
> > Please don't deprecate this symbol.  ARM has a large variety of RTC
> > implementations, some of which reside in I2C modules which are yet
> > to be merged.
> > 
> > Firstly, these aren't accessible until the i2c subsystem has been
> > initialised.  Secondly, i2c is modular, so this function must be
> > accessible from a module in order for the system time/date to be
> > initialised from the RTC with a modular build.
> > 
> > (It can be argued that you wouldn't want to build such a thing as a
> > module in the first place, in which case removing the export would
> > of course be fine.  However, we can't sanely force I2C to be either
> > always builtin, and placing this expectation on people will eventually
> > lead other janitors to complain that the symbol is used by modules but
> > isn't exported.)
> 
> I saw drivers/acorn/char/i2c.c, but this file is always built statically 
> on ARCH_ACORN without any dependency between ARCH_ACORN and I2C.
> This is buggy.
> 
> Why can't such drivers select I2C and other required I2C_* variables?
> 
> Appropriate depends or selects are required in any case.
> If you plan to make drivers like drivers/acorn/char/i2c.c modular, my 
> patch is void.

That driver is buggy for other reasons, but thankfully doesn't show
itself very often...

However, that isn't the one I was talking about, since I was talking
about an unmerged driver.

There are a number of ARM platforms which use a Ricoh RTC chip, and
the driver for this will live in drivers/i2c/chips/ricoh-rtc.c.  This
is a stand alone driver in its own sense, handling the power management
issues (saving the time offset/restoring the time) and setting the
system time upon its initialisation.  (In turn, this requires some i2c
patches which add power management to the i2c subsystem to be merged
first.)

It's already used in some ARM platforms, including one which I was
involved in.  It just hasn't been merged.

As far as drivers/acorn/char i2c rtc stuff goes, I plan to make this
a full and proper i2c citizen, so adding breakage to the Kconfig with
random select statements for publically viewable symbols isn't the
way to go.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[Adrian Bunk]

On Sat, Feb 26, 2005 at 04:46:13PM +0000, Russell King wrote:
>...
> There are a number of ARM platforms which use a Ricoh RTC chip, and
> the driver for this will live in drivers/i2c/chips/ricoh-rtc.c.  This
> is a stand alone driver in its own sense, handling the power management
> issues (saving the time offset/restoring the time) and setting the
> system time upon its initialisation.  (In turn, this requires some i2c
> patches which add power management to the i2c subsystem to be merged
> first.)
> 
> It's already used in some ARM platforms, including one which I was
> involved in.  It just hasn't been merged.
> 
> As far as drivers/acorn/char i2c rtc stuff goes, I plan to make this
> a full and proper i2c citizen, so adding breakage to the Kconfig with
> random select statements for publically viewable symbols isn't the
> way to go.

You call it "breakage" because you have a relatively dogmatic view 
regarding the selection of user visible symbols.
Other people care more about the usability of the kernel config system, 
and therefore a select of one of the I2C* options is quite common from 
both outside and inside the i2c subsystem.

There are two possbile situations:
- these RTC drivers are nice add-ons that could be shown if all
  required I2C* options are already enabled
- these RTC drivers are pretty essential and should really be enabled
  on the platforms they are for

Which of these two cases describes the situation of these RTC drivers?

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] deprecate EXPORT_SYMBOL(do_settimeofday)

[Russell King]

On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote:
> You call it "breakage" because you have a relatively dogmatic view 
> regarding the selection of user visible symbols.
> Other people care more about the usability of the kernel config system, 
> and therefore a select of one of the I2C* options is quite common from 
> both outside and inside the i2c subsystem.
> 
> There are two possbile situations:
> - these RTC drivers are nice add-ons that could be shown if all
>   required I2C* options are already enabled
> - these RTC drivers are pretty essential and should really be enabled
>   on the platforms they are for
> 
> Which of these two cases describes the situation of these RTC drivers?

Since RTCs aren't _actually_ essential for Linux kernel operation,
the former clearly applies.

Other people may have differing opinions, but having worked with a
large number of SoC platforms where the RTC is reset when the SoC
is reset, or even platforms where there is no RTC at all, it brings
a different perspective to this that people who have only ever
experienced systems where the RTC is always true do not have.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[Adrian Bunk]

On Sat, Feb 26, 2005 at 05:20:18PM +0000, Russell King wrote:
> On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote:
> > You call it "breakage" because you have a relatively dogmatic view 
> > regarding the selection of user visible symbols.
> > Other people care more about the usability of the kernel config system, 
> > and therefore a select of one of the I2C* options is quite common from 
> > both outside and inside the i2c subsystem.
> > 
> > There are two possbile situations:
> > - these RTC drivers are nice add-ons that could be shown if all
> >   required I2C* options are already enabled
> > - these RTC drivers are pretty essential and should really be enabled
> >   on the platforms they are for
> > 
> > Which of these two cases describes the situation of these RTC drivers?
> 
> Since RTCs aren't _actually_ essential for Linux kernel operation,
> the former clearly applies.
> 
> Other people may have differing opinions, but having worked with a
> large number of SoC platforms where the RTC is reset when the SoC
> is reset, or even platforms where there is no RTC at all, it brings
> a different perspective to this that people who have only ever
> experienced systems where the RTC is always true do not have.

No problem with this.

I'm hereby withdrawing my 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] deprecate EXPORT_SYMBOL(do_settimeofday)

[Russell King]

On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote:
> You call it "breakage" because you have a relatively dogmatic view 
> regarding the selection of user visible symbols.
> Other people care more about the usability of the kernel config system, 
> and therefore a select of one of the I2C* options is quite common from 
> both outside and inside the i2c subsystem.

I think you have to realise that we're different in the ARM world.
We tend to rely on the default configuration files to come out with
something that works, rather than hard coding the "what works" into
the kernel configuration subsystem.

If you want to see an example of this kind of "usability" approach,
take a look at arch/arm/Kconfig LEDS options - lines of 250 or so
characters of dependencies.  Not what I'd call particularly
maintainable.

That is what your approach has in store for the other Kconfig files
when it comes down to getting dependencies Correct(tm).

(I do have a simplified LEDS configuration set, but it still keeps
one huge LEDS dependency.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

[Adrian Bunk]

On Sat, Feb 26, 2005 at 05:29:22PM +0000, Russell King wrote:
> On Sat, Feb 26, 2005 at 06:13:25PM +0100, Adrian Bunk wrote:
> > You call it "breakage" because you have a relatively dogmatic view 
> > regarding the selection of user visible symbols.
> > Other people care more about the usability of the kernel config system, 
> > and therefore a select of one of the I2C* options is quite common from 
> > both outside and inside the i2c subsystem.
> 
> I think you have to realise that we're different in the ARM world.
> We tend to rely on the default configuration files to come out with
> something that works, rather than hard coding the "what works" into
> the kernel configuration subsystem.
> 
> If you want to see an example of this kind of "usability" approach,
> take a look at arch/arm/Kconfig LEDS options - lines of 250 or so
> characters of dependencies.  Not what I'd call particularly
> maintainable.
> 
> That is what your approach has in store for the other Kconfig files
> when it comes down to getting dependencies Correct(tm).

LEDS=n and LEDS_TIMER=y is a legal configuration if ARCH_EBSA110?

The LEDS_TIMER dependencies seem to be incorrect at least regarding 
ARCH_CDB89712.

Yes, it is ugly annd error-prone.

> (I do have a simplified LEDS configuration set, but it still keeps
> one huge LEDS dependency.)

The current LEDS configuration is ugly, but that's not an ARM specific 
problem. Compare e.g. the big #if in include/linux/parport.h 30 lines 
before the end of the file in Linus' tree and see how this is resolved 
in -mm in non-pc-parport-config-change.patch .

One solution for LEDS would be to add a helper option HAS_LEDS that gets 
selected by the ARCH_* options if the platform supports LEDS, and LEDS 
simply depends on HAS_LEDS.

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