Linux 2.5.40-ac1
+ Initial port of aacraid driver to 2.5 (me)
+ vfat corruption fix (Petr Vandrovec)
+ Clean up firestream warnings (Francois Romieu)
+ Voyager support (James Bottomley)
+ Fix split_vma (Hugh Dickins)
+ Fix config in video subdirectory (John Levon)
+ Update olympic driver to 2.5 (Mike Phillips)
+ Fix sg init error (Mike Anderson)
+ Fix Rules.make
o Merge most of ucLinux stuff (Greg Ungerer)
| It needs putting somewhere so we can pick over the
| hard bits left
| Q: Wouldn't drivers/char/mem-nommu.c be better
| Q: How to do the procfs stuff tidily
| Q: Wouldn't it be nicer to move all mm or mmnommu specific ksyms
| int the relevant mm/*.c file area instead of kernel/ksyms
| Q: Why ifdef out overcommit - its even easier to account on
| MMUless and useful info
+ Stick tulip back under 10/100 ethernet (me)
+ Correct docs for IBM touchpad back to how (me)
they were before
o Fix abuse of set_bit in winbond-840 (me)
+ Fix abuse of set_bit in atp (me)
--
"When Dilbert has a better working environment than you
its time to leave"
- Anonymous
Hi Alan,
> Linux 2.5.40-ac1
[snip]
> o Merge most of ucLinux stuff (Greg Ungerer)
Woohoo!
> | It needs putting somewhere so we can pick over the
> | hard bits left
> | Q: Wouldn't drivers/char/mem-nommu.c be better
OK, that is easy to do...
> | Q: How to do the procfs stuff tidily
Yes. I need to spend some time on this one. Just lots
of little differences...
> | Q: Wouldn't it be nicer to move all mm or mmnommu specific ksyms
> | int the relevant mm/*.c file area instead of kernel/ksyms
OK, I have a new patch today that cleans all this up.
I made all the existing ksysms symbols present. It turns out
many where already there in my more recent patches anyway.
A couple needed to be stubbed. The next patch has no diffs
to ksyms at all.
> | Q: Why ifdef out overcommit - its even easier to account on
> | MMUless and useful info
I was looking over this yesterday too. Should be able to clean this
up a bit.
What do you think about the separate mm/mmnommu directories
at the top level? Should the mmnommu be merged into mm?
Do you want me to CC you when I put new patches up?
Thanks
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
> The sepearate one is horrible maintaince wise. Please introduce
> CONFIG_MMU and try to make as many _files_ in mm/ conditional on
> those. Else use the proper ways (cond_syscall(), inline stubs) to
> hide the differences.
The two are so different I think that keeping it seperate is actually the
right idea personally. It will be up to the nommu people to chase the "real
computer" mmu code but I don't think that is a problem.
Some of the other areas you really do want to just hide the differences
nicely - eg in proc
On Thu, Oct 03, 2002 at 09:38:11AM +1000, Greg Ungerer wrote:
> What do you think about the separate mm/mmnommu directories
> at the top level? Should the mmnommu be merged into mm?
The sepearate one is horrible maintaince wise. Please introduce
CONFIG_MMU and try to make as many _files_ in mm/ conditional on
those. Else use the proper ways (cond_syscall(), inline stubs) to
hide the differences.
On Thu, Oct 03, 2002 at 10:20:03AM -0400, Alan Cox wrote:
> > The sepearate one is horrible maintaince wise. Please introduce
> > CONFIG_MMU and try to make as many _files_ in mm/ conditional on
> > those. Else use the proper ways (cond_syscall(), inline stubs) to
> > hide the differences.
>
> The two are so different I think that keeping it seperate is actually the
> right idea personally.
Did you actually take a look? Many files are basically the same and other
are just totally stubbed out in nommu.
> o Fix abuse of set_bit in winbond-840 (me)
Were there bug reports, Have you tested the change?
I think the cpu_to_le32 is wrong.
On big endian computers, the nic is set into a big-endian mode, and it
did work with set_bit on my power mac. Unfortunately, I don't have
access to it right now.
--
Manfred
On Thu, 2002-10-03 at 15:51, Christoph Hellwig wrote:
> Did you actually take a look? Many files are basically the same and other
> are just totally stubbed out in nommu.
Basically but never entirely - if you can see a way to clean that up
nicely that Linus would accept other than mmnommu then thats even
better. I couldnt see a way of getting enough ifdefs out of the tree
Alan Cox wrote:
> On Thu, 2002-10-03 at 15:51, Christoph Hellwig wrote:
>
>>Did you actually take a look? Many files are basically the same and other
>>are just totally stubbed out in nommu.
>
>
> Basically but never entirely - if you can see a way to clean that up
> nicely that Linus would accept other than mmnommu then thats even
> better. I couldnt see a way of getting enough ifdefs out of the tree
And this really is the problem. There is a lot of ifdefs, lots
of little differences. I am not sure how exactly we could
clean this up.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
Alan Cox wrote:
>
> The checks I did were that it seemed to produce the same data in both
> cases. So if it was wrong before (using set_bit) its probably wrong now.
>
Which arch?
On ppc, __set_bit() stores in big endian format, i.e. the cpu_to_le32
would be wrong
I try to figure out what set_bit() does.
--
Manfred
From: Manfred Spraul <[email protected]>
Date: Thu, 03 Oct 2002 17:18:06 +0200
Patch again attached, but untested.
I'm fine with it, just make sure it doesn't give Linus heart burn :-)
On Thu, Oct 03, 2002 at 04:25:38PM +0100, Alan Cox wrote:
> On Thu, 2002-10-03 at 15:51, Christoph Hellwig wrote:
> > Did you actually take a look? Many files are basically the same and other
> > are just totally stubbed out in nommu.
>
> Basically but never entirely - if you can see a way to clean that up
> nicely that Linus would accept other than mmnommu then thats even
> better. I couldnt see a way of getting enough ifdefs out of the tree
I'll start feeding patches once I'm back from a small journey
--- 2.4/include/linux/bitops.h Sat Apr 28 00:48:19 2001
+++ build-2.4/include/linux/bitops.h Tue Jun 5 19:40:43 2001
@@ -68,5 +68,27 @@
#include <asm/bitops.h>
+#ifdef __KERNEL__
+#include <linux/types.h>
+#define BUILD_SET_BIT(n) \
+static inline void __set_bit_##n(int offset, u##n *data) \
+{ \
+ data[offset/n] |= (1 << (offset%n)); \
+}
+
+#ifndef _HAVE_ARCH_SET_BIT_8
+BUILD_SET_BIT(8)
+#endif
+#ifndef _HAVE_ARCH_SET_BIT_16
+BUILD_SET_BIT(16)
+#endif
+#ifndef _HAVE_ARCH_SET_BIT_32
+BUILD_SET_BIT(32)
+#endif
+#ifndef _HAVE_ARCH_SET_BIT_64
+BUILD_SET_BIT(64)
+#endif
+#undef BUILD_SET_BIT
+#endif
#endif
From: Manfred Spraul <[email protected]>
Date: Thu, 03 Oct 2002 16:45:59 +0200
On big endian computers, the nic is set into a big-endian mode, and it
did work with set_bit on my power mac. Unfortunately, I don't have
access to it right now.
How about a 64-bit system where set_bit works on 64-bit longs
and not 32-bit ones? That is why the current code there is broken.
On Thu, 2002-10-03 at 16:18, Manfred Spraul wrote:
> There should bit nonatomic bit ops for every byte width.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=99167415926343&w=2
>
> I even sent you the patch proposal, but never got a reply.
>
> Patch again attached, but untested.
What about reverse endianness ?
On Thu, 2002-10-03 at 15:45, Manfred Spraul wrote:
> > o Fix abuse of set_bit in winbond-840 (me)
>
> Were there bug reports, Have you tested the change?
Yes and no - I don't have an 840
> I think the cpu_to_le32 is wrong.
>
> On big endian computers, the nic is set into a big-endian mode, and it
> did work with set_bit on my power mac. Unfortunately, I don't have
> access to it right now.
The checks I did were that it seemed to produce the same data in both
cases. So if it was wrong before (using set_bit) its probably wrong now.
Alan Cox wrote:
> On Thu, 2002-10-03 at 16:18, Manfred Spraul wrote:
>
>>There should bit nonatomic bit ops for every byte width.
>>
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=99167415926343&w=2
>>
>>I even sent you the patch proposal, but never got a reply.
>>
>>Patch again attached, but untested.
>
>
> What about reverse endianness ?
AFAIK, writeX macros should swap as needed, i.e.
writel(0x100,ioaddr);
should arrive as bit 8 set on the hardware. [please correct me if I'm
wrong] Thus the input into write{b,w,l} should be in host byte order.
u{8,16,32} array[];
__set_bit_{8,16,32}(,array);
write{b,w,l}(array[],ioaddr);
would achieve that.
On Thu, 3 Oct 2002, Christoph Hellwig wrote:
> On Thu, Oct 03, 2002 at 10:20:03AM -0400, Alan Cox wrote:
> > The two are so different I think that keeping it seperate is actually the
> > right idea personally.
>
> Did you actually take a look? Many files are basically the same and other
> are just totally stubbed out in nommu.
So how about having one mm/ directory with:
1) the common stuff
2) the MMU stuff
3) the NOMMU stuff
... and some magic in Makefile to select which .c files to
compile ?
That should keep code duplication to a minimum.
regards,
Rik
--
A: No.
Q: Should I include quotations after my reply?
http://www.surriel.com/ http://distro.conectiva.com/
Hi Rik,
Rik van Riel wrote:
> On Thu, 3 Oct 2002, Christoph Hellwig wrote:
>
>>On Thu, Oct 03, 2002 at 10:20:03AM -0400, Alan Cox wrote:
>
>
>>>The two are so different I think that keeping it seperate is actually the
>>>right idea personally.
>>
>>Did you actually take a look? Many files are basically the same and other
>>are just totally stubbed out in nommu.
>
>
> So how about having one mm/ directory with:
>
> 1) the common stuff
> 2) the MMU stuff
> 3) the NOMMU stuff
>
> ... and some magic in Makefile to select which .c files to
> compile ?
>
> That should keep code duplication to a minimum.
Easy done. Would it bother anyone having a few files
named XYZ-nommu.c in there?
Although the sticking point may be the common files that
still contain a lot of ifdefs.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
On Fri, 4 Oct 2002, Greg Ungerer wrote:
> Rik van Riel wrote:
> Easy done. Would it bother anyone having a few files
> named XYZ-nommu.c in there?
Excellent.
> Although the sticking point may be the common files that
> still contain a lot of ifdefs.
That's ok initially. We can probably split up functions
somewhat or do other tricks to reduce the number of
ifdefs later on.
Alternatively, we could do the splitting first and the
nommu merge later. I don't really care about the order
as long as things don't happen simultaneously in patch
that's too big to check ;)
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Spamtraps of the month: [email protected] [email protected]