A commit that does nothing except for adding two unused EXPORT_SYMBOL's.
Without any rationale why they should be exported.
And that from a person who on the other hand wants to introduce
(and tries to force on other people) deprecation periods for unused
EXPORT_SYMBOL's.
Can we please get this reverted quickly?
TIA
Adrian
commit 914c82694cadbab511f2aee8a59c89be2938bace
Author: Andrew Morton <[email protected]>
Date: Wed Jan 30 23:27:57 2008 +0100
x86: export copy_from_user_ll_nocache[_nozero]
Cc: Neil Brown <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
diff --git a/arch/x86/lib/usercopy_32.c b/arch/x86/lib/usercopy_32.c
index 8bab2b2..9c4ffd5 100644
--- a/arch/x86/lib/usercopy_32.c
+++ b/arch/x86/lib/usercopy_32.c
@@ -817,6 +817,7 @@ unsigned long __copy_from_user_ll_nocache(void *to, const void __user *from,
#endif
return n;
}
+EXPORT_SYMBOL(__copy_from_user_ll_nocache);
unsigned long __copy_from_user_ll_nocache_nozero(void *to, const void __user *from,
unsigned long n)
@@ -831,6 +832,7 @@ unsigned long __copy_from_user_ll_nocache_nozero(void *to, const void __user *fr
#endif
return n;
}
+EXPORT_SYMBOL(__copy_from_user_ll_nocache_nozero);
/**
* copy_to_user: - Copy a block of data into user space.
* Adrian Bunk <[email protected]> wrote:
> A commit that does nothing except for adding two unused
> EXPORT_SYMBOL's.
>
> Without any rationale why they should be exported.
the rationale is obvious: it's part of the standard uaccess
functionality and while it's rarely used (in fact it's not used by any
modular code right now) there's no reason not to export it alongside the
other uaccess vectors. We can unexport it once we unexport all uses of
the uaccess APIs. We could make it a _GPL export perhaps.
It's very annoying to driver writers when a small portion of a sensible
API vector is not available symmetrically.
> And that from a person who on the other hand wants to introduce (and
> tries to force on other people) deprecation periods for unused
> EXPORT_SYMBOL's.
why does this bother you? The API makes total sense. This is a
completely sensible API (with a full implementation) to use non-temporal
copies. I mean, if this was some legacy API that nobody uses anymore i'd
agree, but this is about the ability to access user-space memory via
SSE2+ non-temporal stores.
Ingo
On Thu, 31 Jan 2008 22:14:30 +0200
Adrian Bunk <[email protected]> wrote:
> A commit that does nothing except for adding two unused EXPORT_SYMBOL's.
>
> Without any rationale why they should be exported.
Don't look at me. This has been sitting in my tree for nearly two years as
part of the reiser4 patchset. It may not even be needed any more. I guess
Ingo went on a fishing expedition and liked the change.
> And that from a person who on the other hand wants to introduce
> (and tries to force on other people) deprecation periods for unused
> EXPORT_SYMBOL's.
For very good reasons which you perversely and persistently ignore.
* Andrew Morton <[email protected]> wrote:
> > A commit that does nothing except for adding two unused
> > EXPORT_SYMBOL's.
> >
> > Without any rationale why they should be exported.
>
> Don't look at me. This has been sitting in my tree for nearly two
> years as part of the reiser4 patchset. It may not even be needed any
> more. I guess Ingo went on a fishing expedition and liked the change.
yes, i picked it up from -mm (as can be seen from the SOB line), and i
agreed with that change regardless of the reiser4 patchset. (which might
never see the light of upstream acceptance)
there's nothing more annoying than incomplete and inconsistent APIs. I'm
trying to fix them up everywhere i see, and this is one of those cases.
Adrian still has not given any rationale about why he wants to see the
export removed.
Ingo
* Ingo Molnar <[email protected]> wrote:
> > And that from a person who on the other hand wants to introduce (and
> > tries to force on other people) deprecation periods for unused
> > EXPORT_SYMBOL's.
>
> why does this bother you? The API makes total sense. This is a
> completely sensible API (with a full implementation) to use
> non-temporal copies. I mean, if this was some legacy API that nobody
> uses anymore i'd agree, but this is about the ability to access
> user-space memory via SSE2+ non-temporal stores.
Adrian, you have still not answered the (obvious) question: why do such
currently-unused exports bother you?
Ingo
On Thu, Jan 31, 2008 at 01:05:29PM -0800, Andrew Morton wrote:
> On Thu, 31 Jan 2008 22:14:30 +0200
> Adrian Bunk <[email protected]> wrote:
>
> > A commit that does nothing except for adding two unused EXPORT_SYMBOL's.
> >
> > Without any rationale why they should be exported.
>
> Don't look at me. This has been sitting in my tree for nearly two years as
> part of the reiser4 patchset. It may not even be needed any more. I guess
> Ingo went on a fishing expedition and liked the change.
>...
Sorry Andrew.
I misunderstood the patch flow.
And much more important, the tone of my email was not appropriate.
Due to unrelated reasons I was Thursday evening in a mood in which I
should not have left emails out of my postponed folder without sleeping
a night over them.
I hope you accept my apology.
Yours
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
On Sat, 2 Feb 2008 23:36:28 +0200 Adrian Bunk <[email protected]> wrote:
> On Thu, Jan 31, 2008 at 01:05:29PM -0800, Andrew Morton wrote:
> > On Thu, 31 Jan 2008 22:14:30 +0200
> > Adrian Bunk <[email protected]> wrote:
> >
> > > A commit that does nothing except for adding two unused EXPORT_SYMBOL's.
> > >
> > > Without any rationale why they should be exported.
> >
> > Don't look at me. This has been sitting in my tree for nearly two years as
> > part of the reiser4 patchset. It may not even be needed any more. I guess
> > Ingo went on a fishing expedition and liked the change.
> >...
>
> Sorry Andrew.
>
> I misunderstood the patch flow.
>
> And much more important, the tone of my email was not appropriate.
>
> Due to unrelated reasons I was Thursday evening in a mood in which I
> should not have left emails out of my postponed folder without sleeping
> a night over them.
I know the feeling.
> I hope you accept my apology.
No probs. But it's not really needed - this is lkml. We shout at each
other, get over it and get on with stuff.
* Adrian Bunk <[email protected]> wrote:
> Sorry Andrew.
>
> I misunderstood the patch flow.
>
> And much more important, the tone of my email was not appropriate.
>
> Due to unrelated reasons I was Thursday evening in a mood in which I
> should not have left emails out of my postponed folder without
> sleeping a night over them.
>
> I hope you accept my apology.
i'd like to apologize to you too Adrian - i should have been (a lot)
more patient as well - the merge window is not for the faint hearted i
guess :-/
Ingo
> * Adrian Bunk <[email protected]> wrote:
>
> > Sorry Andrew.
> >
> > I misunderstood the patch flow.
> >
> > And much more important, the tone of my email was not appropriate.
> >
> > Due to unrelated reasons I was Thursday evening in a mood in which I
> > should not have left emails out of my postponed folder without
> > sleeping a night over them.
> >
> > I hope you accept my apology.
>
> i'd like to apologize to you too Adrian - i should have been (a lot)
> more patient as well - the merge window is not for the faint hearted i
> guess :-/
Apology accepted.
> Ingo
cu
Adrian
BTW: Your emails really brought me near to leaving kernel development.
--
"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