LinuxLists.cc - [2.6 patch] unexport do

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

Adrian Bunk <[email protected]> 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

2005-02-25 08:02:17

by Arjan van de Ven

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

On Thu, 2005-02-24 at 21:24 -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> 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???

2005-02-25 08:31:42

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

Arjan van de Ven <[email protected]> wrote:
>
> On Thu, 2005-02-24 at 21:24 -0800, Andrew Morton wrote:
> > Adrian Bunk <[email protected]> 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.

2005-02-25 08:47:06

by Bartlomiej Zolnierkiewicz

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

On Fri, 25 Feb 2005 00:28:04 -0800, Andrew Morton <[email protected]> wrote:
> Arjan van de Ven <[email protected]> wrote:
> >
> > On Thu, 2005-02-24 at 21:24 -0800, Andrew Morton wrote:
> > > Adrian Bunk <[email protected]> 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?

2005-02-25 09:26:46

by Andreas Dilger

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

On Feb 25, 2005 09:47 +0100, Bartlomiej Zolnierkiewicz wrote:
> On Fri, 25 Feb 2005 00:28:04 -0800, Andrew Morton <[email protected]> wrote:
> > Adrian Bunk <[email protected]> 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

2005-02-25 09:33:48

by Arjan van de Ven

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

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 <[email protected]> wrote:
> > > Adrian Bunk <[email protected]> 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?

2005-02-25 09:50:08

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

Arjan van de Ven <[email protected]> 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.

2005-02-25 21:43:42

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

On Thu, Feb 24, 2005 at 09:24:48PM -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> 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

2005-02-25 21:58:41

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

Adrian Bunk <[email protected]> wrote:
>
> On Thu, Feb 24, 2005 at 09:24:48PM -0800, Andrew Morton wrote:
> > Adrian Bunk <[email protected]> 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
_

2005-02-25 23:05:04

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

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

2005-02-25 23:18:39

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

Adrian Bunk <[email protected]> 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.

2005-02-26 10:01:38

by Arjan van de Ven

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

On Fri, 2005-02-25 at 15:20 -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> 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)

2005-02-26 13:33:42

[permalink] [raw]

Subject: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

Signed-off-by: Adrian Bunk <[email protected]>

--- 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 <[email protected]>

+---------------------------
+
+What: EXPORT_SYMBOL(do_settimeofday)
+When: 26 Aug 2005
+Files: arch/*/kernel/time.c
+Why: not used in the kernel
+Who: Adrian Bunk <[email protected]>
--- 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);

2005-02-26 13:36:25

by YOSHIFUJI Hideaki

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

In article <[email protected]> (at Sat, 26 Feb 2005 14:33:37 +0100), Adrian Bunk <[email protected]> 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 <[email protected]>

--yoshfuji

2005-02-26 13:37:13

by YOSHIFUJI Hideaki

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

In article <[email protected]> (at Sat, 26 Feb 2005 22:37:42 +0900 (JST)), YOSHIFUJI Hideaki / $B5HF#1QL@(B <[email protected]> says:

> In article <[email protected]> (at Sat, 26 Feb 2005 14:33:37 +0100), Adrian Bunk <[email protected]> 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 <[email protected]>

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

--yoshfuji

2005-02-26 14:46:45

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

On Sat, Feb 26, 2005 at 02:33:37PM +0100, Adrian Bunk wrote:
> Signed-off-by: Adrian Bunk <[email protected]>

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

2005-02-26 15:22:45

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

On Fri, Feb 25, 2005 at 03:20:09PM -0800, Andrew Morton wrote:
> Adrian Bunk <[email protected]> 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

2005-02-26 15:29:01

[permalink] [raw]

Subject: Re: [2.6 patch] unexport do_settimeofday

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 <[email protected]> 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

2005-02-26 16:23:52

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

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

2005-02-26 16:46:26

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

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

2005-02-26 17:13:30

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

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

2005-02-26 17:20:43

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

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

2005-02-26 17:29:30

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

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

2005-02-27 00:28:27

[permalink] [raw]

Subject: Re: [2.6 patch] deprecate EXPORT_SYMBOL(do_settimeofday)

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

2005-02-27 00:43:22