Re: Linux 2.5.40-ac1

Re: Linux 2.5.40-ac1

[Manfred Spraul]

 > 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

Re: Linux 2.5.40-ac1

[David S. Miller]

   From: Manfred Spraul <manfred@colorfullife.com>
   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.

Re: Linux 2.5.40-ac1

[David S. Miller]

   From: Manfred Spraul <manfred@colorfullife.com>
   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 :-)

Re: Linux 2.5.40-ac1

[Alan Cox]

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.

Re: Linux 2.5.40-ac1

[Manfred Spraul]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

David S. Miller wrote:
>    
> 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.
 >

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.
--
	Manfred

[-- Attachment #2: patch-bitops --]
[-- Type: text/plain, Size: 620 bytes --]

--- 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

Re: Linux 2.5.40-ac1

[Manfred Spraul]

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

Re: Linux 2.5.40-ac1

[Alan Cox]

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 ?

Re: Linux 2.5.40-ac1

[Manfred Spraul]

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.

Re: Linux 2.5.40-ac1

[Rik van Riel]

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:  september@surriel.com trac@trac.org

Re: Linux 2.5.40-ac1

[Greg Ungerer]

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:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com

Re: Linux 2.5.40-ac1

[Rik van Riel]

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/

Re: Linux 2.5.40-ac1

[Greg Ungerer]

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:  gerg@snapgear.com
Snapgear Pty Ltd                               PHONE:    +61 7 3279 1822
825 Stanley St,                                  FAX:    +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com

Re: Linux 2.5.40-ac1

[Christoph Hellwig]

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

Re: Linux 2.5.40-ac1

[Alan Cox]

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

Re: Linux 2.5.40-ac1

[Christoph Hellwig]

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.

Re: Linux 2.5.40-ac1

[Alan Cox]

> 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

Re: Linux 2.5.40-ac1

[Christoph Hellwig]

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.

Re: Linux 2.5.40-ac1

[Greg Ungerer]

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:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com

Linux 2.5.40-ac1

[Alan Cox]

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