Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-27 Thread Adrian Bunk
On Fri, Jun 27, 2008 at 01:23:05AM +0200, Arnd Bergmann wrote:
 On Thursday 26 June 2008, Adrian Bunk wrote:
  Honestly, I do not completely like your approach of getting the 
  microblaze port submitter to create the asm-generic files - I would 
  personally prefer if the microblaze port would look exactly like all 
  other ports and the (reasonable) changes you have in mind were not
  being discussed and done as part of the submission of a new port.
 
 But it works really well this way ;-). My point is that a new port
 should look just like all the other ports should have looked as
 well, not like they did. When it comes to the ABI, you
 cannot make incompatible changes after it's merged, so IMHO all
 ABI defining headers should go to asm-generic if possible.
...

For the ABI it doesn't matter where the headers are.

  After all, it won't matter whether we'll unify resp. remove
  22 or 23 files.
 
 That wasn't my idea. The logic was that if one more file exists
 in asm-generic that can be removed from the architectures,
 we get 22 more files to remove without anyone having to look
 at the big picture. When microblaze is in,

Discussions of the big picture should be in an own thread, not as 
part of a merge of a new architecture.

I am not an architecture maintainer, but I do not like the way you want 
to couple the microblaze merge with the move of stuff to asm-generic.

They both make sense, but they are clearly separate issues.

 I can compile a list
 with asm-generic files that can be used to replace the architecture
 specific files, so the arch maintainers can decide on their own
 whether to clean their own stuff up or not.
...

We need either all architectures changed or none at all - we do need the 
arch headers to become more similar, not more different.

And this is why we need an agreement _before_ an asm-generic header gets 
added, not after it.

   Arnd 

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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-27 Thread Michal Simek
Hi Adrian and Arnd,

  After all, it won't matter whether we'll unify resp. remove
  22 or 23 files.
 
 That wasn't my idea. The logic was that if one more file exists
 in asm-generic that can be removed from the architectures,
 we get 22 more files to remove without anyone having to look
 at the big picture. When microblaze is in,

Discussions of the big picture should be in an own thread, not as 
part of a merge of a new architecture.

I am not an architecture maintainer, but I do not like the way you want 
to couple the microblaze merge with the move of stuff to asm-generic.

They both make sense, but they are clearly separate issues.

 I can compile a list
 with asm-generic files that can be used to replace the architecture
 specific files, so the arch maintainers can decide on their own
 whether to clean their own stuff up or not.
...

We need either all architectures changed or none at all - we do need the 
arch headers to become more similar, not more different.

And this is why we need an agreement _before_ an asm-generic header gets 
added, not after it.

I moved some headers to asm-generic how Arnd recommended to me. The same style
is applied to of files. If you think that is good idea to start with new topic 
what is necessary to move
to asm-generic, I agree. For me is not hard to move these files back to 
asm-microblaze and then
someone can do big patch among all archs.
If you want to managed, please open new discussion about and cc me.

Michal
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-27 Thread Sam Ravnborg
 
 We need either all architectures changed or none at all - we do need the 
 arch headers to become more similar, not more different.
 
 And this is why we need an agreement _before_ an asm-generic header gets 
 added, not after it.
We already have the agreement..
Files which are equal among archs should be in asm-generic.
And there is simply no gain in adding files for an arch when can put
them in asm-generic.
When they are in asm-generic than we can fix the other archs one-by-one.

Sam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread monstr
From: Michal Simek [EMAIL PROTECTED]


Signed-off-by: Michal Simek [EMAIL PROTECTED]
---
 include/asm-microblaze/cputime.h   |1 +
 include/asm-microblaze/div64.h |1 +
 include/asm-microblaze/emergency-restart.h |1 +
 include/asm-microblaze/errno.h |1 +
 include/asm-microblaze/futex.h |1 +
 include/asm-microblaze/kdebug.h|1 +
 include/asm-microblaze/local.h |1 +
 include/asm-microblaze/mutex.h |1 +
 include/asm-microblaze/namei.h |   22 ++
 include/asm-microblaze/percpu.h|1 +
 include/asm-microblaze/resource.h  |1 +
 11 files changed, 32 insertions(+), 0 deletions(-)
 create mode 100644 include/asm-microblaze/auxvec.h
 create mode 100644 include/asm-microblaze/cputime.h
 create mode 100644 include/asm-microblaze/div64.h
 create mode 100644 include/asm-microblaze/emergency-restart.h
 create mode 100644 include/asm-microblaze/errno.h
 create mode 100644 include/asm-microblaze/futex.h
 create mode 100644 include/asm-microblaze/kdebug.h
 create mode 100644 include/asm-microblaze/local.h
 create mode 100644 include/asm-microblaze/mutex.h
 create mode 100644 include/asm-microblaze/namei.h
 create mode 100644 include/asm-microblaze/percpu.h
 create mode 100644 include/asm-microblaze/resource.h
 create mode 100644 include/asm-microblaze/user.h

diff --git a/include/asm-microblaze/auxvec.h b/include/asm-microblaze/auxvec.h
new file mode 100644
index 000..e69de29
diff --git a/include/asm-microblaze/cputime.h b/include/asm-microblaze/cputime.h
new file mode 100644
index 000..6d68ad7
--- /dev/null
+++ b/include/asm-microblaze/cputime.h
@@ -0,0 +1 @@
+#include asm-generic/cputime.h
diff --git a/include/asm-microblaze/div64.h b/include/asm-microblaze/div64.h
new file mode 100644
index 000..6cd978c
--- /dev/null
+++ b/include/asm-microblaze/div64.h
@@ -0,0 +1 @@
+#include asm-generic/div64.h
diff --git a/include/asm-microblaze/emergency-restart.h 
b/include/asm-microblaze/emergency-restart.h
new file mode 100644
index 000..3711bd9
--- /dev/null
+++ b/include/asm-microblaze/emergency-restart.h
@@ -0,0 +1 @@
+#include asm-generic/emergency-restart.h
diff --git a/include/asm-microblaze/errno.h b/include/asm-microblaze/errno.h
new file mode 100644
index 000..4c82b50
--- /dev/null
+++ b/include/asm-microblaze/errno.h
@@ -0,0 +1 @@
+#include asm-generic/errno.h
diff --git a/include/asm-microblaze/futex.h b/include/asm-microblaze/futex.h
new file mode 100644
index 000..0b74582
--- /dev/null
+++ b/include/asm-microblaze/futex.h
@@ -0,0 +1 @@
+#include asm-generic/futex.h
diff --git a/include/asm-microblaze/kdebug.h b/include/asm-microblaze/kdebug.h
new file mode 100644
index 000..6ece1b0
--- /dev/null
+++ b/include/asm-microblaze/kdebug.h
@@ -0,0 +1 @@
+#include asm-generic/kdebug.h
diff --git a/include/asm-microblaze/local.h b/include/asm-microblaze/local.h
new file mode 100644
index 000..c11c530
--- /dev/null
+++ b/include/asm-microblaze/local.h
@@ -0,0 +1 @@
+#include asm-generic/local.h
diff --git a/include/asm-microblaze/mutex.h b/include/asm-microblaze/mutex.h
new file mode 100644
index 000..ff6101a
--- /dev/null
+++ b/include/asm-microblaze/mutex.h
@@ -0,0 +1 @@
+#include asm-generic/mutex-dec.h
diff --git a/include/asm-microblaze/namei.h b/include/asm-microblaze/namei.h
new file mode 100644
index 000..61d60b8
--- /dev/null
+++ b/include/asm-microblaze/namei.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2006 Atmark Techno, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#ifndef _ASM_MICROBLAZE_NAMEI_H
+#define _ASM_MICROBLAZE_NAMEI_H
+
+#ifdef __KERNEL__
+
+/* This dummy routine maybe changed to something useful
+ * for /usr/gnemul/ emulation stuff.
+ * Look at asm-sparc/namei.h for details.
+ */
+#define __emul_prefix() NULL
+
+#endif /* __KERNEL__ */
+
+#endif /* _ASM_MICROBLAZE_NAMEI_H */
diff --git a/include/asm-microblaze/percpu.h b/include/asm-microblaze/percpu.h
new file mode 100644
index 000..06a959d
--- /dev/null
+++ b/include/asm-microblaze/percpu.h
@@ -0,0 +1 @@
+#include asm-generic/percpu.h
diff --git a/include/asm-microblaze/resource.h 
b/include/asm-microblaze/resource.h
new file mode 100644
index 000..04bc4db
--- /dev/null
+++ b/include/asm-microblaze/resource.h
@@ -0,0 +1 @@
+#include asm-generic/resource.h
diff --git a/include/asm-microblaze/user.h b/include/asm-microblaze/user.h
new file mode 100644
index 000..e69de29
-- 
1.5.4.GIT

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread Arnd Bergmann
On Thursday 26 June 2008, [EMAIL PROTECTED] wrote:
 +
 +#ifndef _ASM_MICROBLAZE_NAMEI_H
 +#define _ASM_MICROBLAZE_NAMEI_H
 +
 +#ifdef __KERNEL__
 +
 +/* This dummy routine maybe changed to something useful
 + * for /usr/gnemul/ emulation stuff.
 + * Look at asm-sparc/namei.h for details.
 + */
 +#define __emul_prefix() NULL
 +
 +#endif /* __KERNEL__ */
 +
 +#endif /* _ASM_MICROBLAZE_NAMEI_H */

Could you move this to asm-generic? Note that the comment is wrong,
asm-sparc doesn't actually implement it any more, only ia64, mips and
arm have an implementation that actually does something interesting
here.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread Adrian Bunk
On Thu, Jun 26, 2008 at 05:35:11PM +0200, Arnd Bergmann wrote:
 On Thursday 26 June 2008, [EMAIL PROTECTED] wrote:
  +
  +#ifndef _ASM_MICROBLAZE_NAMEI_H
  +#define _ASM_MICROBLAZE_NAMEI_H
  +
  +#ifdef __KERNEL__
  +
  +/* This dummy routine maybe changed to something useful
  + * for /usr/gnemul/ emulation stuff.
  + * Look at asm-sparc/namei.h for details.
  + */
  +#define __emul_prefix() NULL
  +
  +#endif /* __KERNEL__ */
  +
  +#endif /* _ASM_MICROBLAZE_NAMEI_H */
 
 Could you move this to asm-generic? Note that the comment is wrong,
 asm-sparc doesn't actually implement it any more, only ia64, mips and
 arm have an implementation that actually does something interesting
 here.

The comment could be nuked (as well as the #ifdef __KERNEL__), but for 
the one #define an asm-generic header would IMHO be overkill.

   Arnd 

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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread H. Peter Anvin

Arnd Bergmann wrote:

On Thursday 26 June 2008, Adrian Bunk wrote:
The comment could be nuked (as well as the #ifdef __KERNEL__), but for 
the one #define an asm-generic header would IMHO be overkill.


I agree that it doesn't technically make sense to have a one-line
asm-generic header, but I like the idea of reducing the number of
asm/*.h files that actually contain anything other that
#include asm-generic/$FILE.h, mostly for documentation purposes.

If we can eventually agree on a way to get rid of the requirement
for explicit redirection, we can remove a larger number of source
files completely.



The sanest way to do that would probably be something along the lines of:

- Change include/asm-xxx to arch/xxx/include/asm
- Create arch/generic
- Make sure arch/xxx/include/asm and arch/generic/include/asm are both 
in the include path, in that order.


That would also get rid of the symlink.

On the other hand, the redirection isn't all that bad.

-hpa
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread Arnd Bergmann
On Thursday 26 June 2008, H. Peter Anvin wrote:
 
 The sanest way to do that would probably be something along the lines of:
 
 - Change include/asm-xxx to arch/xxx/include/asm

Sam Ravnborg is already working on this part.

 - Create arch/generic
 - Make sure arch/xxx/include/asm and arch/generic/include/asm are both 
 in the include path, in that order.
 
 That would also get rid of the symlink.

It requires two more steps:

- change all remaining users of #include asm-generic/*.h to include
that file with the new name, e.g. #include generic/asm/foo.h if we
have it in the right path.
- change the way 'make headers_install' works so that the files get
installed to the right location in $PREFIX/include/asm/ instead of
$PREFIX/include/asm-generic/ for each header that does not exist
in arch/foo/include/asm.

These changes are probably somewhat controversial, and the first
one is much more invasive than the patches that Sam has, so I'd
not want to do them at the same time.

 On the other hand, the redirection isn't all that bad.

Agreed. I just have the hope that someone comes up with the magical
solution for this problem that makes it a lot nicer than the suggestions
so far or the current way of doing it ;-)

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 48/60] microblaze_v4: headers simple files - empty or redirect to asm-generic

2008-06-26 Thread Arnd Bergmann
On Thursday 26 June 2008, Adrian Bunk wrote:
 Honestly, I do not completely like your approach of getting the 
 microblaze port submitter to create the asm-generic files - I would 
 personally prefer if the microblaze port would look exactly like all 
 other ports and the (reasonable) changes you have in mind were not
 being discussed and done as part of the submission of a new port.

But it works really well this way ;-). My point is that a new port
should look just like all the other ports should have looked as
well, not like they did. When it comes to the ABI, you
cannot make incompatible changes after it's merged, so IMHO all
ABI defining headers should go to asm-generic if possible.

Since there doesn't seem to be anyone investing work into moving the
files there (I started it before, but got bored before submitting
them all myself), the point of adding a new architecture is exactly
the right one for putting the file to asm-generic. For Michal, there
is no difference between putting the file into asm-generic or
asm-microblaze, other than that he has to change his existing
patch once, but in return he gets fewer files to maintain afterwards.

The fundamental principle here is: if you want your code to get in,
do it in a way that makes your own code cleaner by making it cleaner
for everyone else as well.
The result is that more people look at the code, and that Michal's
name gets more widely known, so the next time he needs something
from another developer, he's more likely to get heard because
you think of him as the person that did all the useful work on
the asm-generic files.

 After all, it won't matter whether we'll unify resp. remove
 22 or 23 files.

That wasn't my idea. The logic was that if one more file exists
in asm-generic that can be removed from the architectures,
we get 22 more files to remove without anyone having to look
at the big picture. When microblaze is in, I can compile a list
with asm-generic files that can be used to replace the architecture
specific files, so the arch maintainers can decide on their own
whether to clean their own stuff up or not.

With namei.h, I may have gone too far to request moving it
to asm-generic as part of the microblaze merge, because it's
not an ABI header, but I think it's a step in the right direction
anyway, and I may put it there myself if I ever get to do
my how to port Linux to a new architecture the right way paper.

Arnd 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev