Linux 2.5.40-ac1
Hi Alan,
Quoted 1 line
Linux 2.5.40-ac1
[snip]
Quoted 1 line
o Merge most of ucLinux stuff (Greg Ungerer)
Woohoo!
Quoted 3 lines
| 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...
Quoted 1 line
| Q: How to do the procfs stuff tidily
Yes. I need to spend some time on this one. Just lots of little differences...
Quoted 2 lines
| Q: Wouldn't it be nicer to move all mm or mmnommu specific ksyms
| int the relevantmm/*.cfile 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.
Quoted 2 lines
| 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: www.SnapGear.com
Quoted 2 lines · Greg Ungerer
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.
Quoted 4 lines
The sepearate one is horrible maintaince wise. Please introduce
CONFIG_MMUand try to make as many _files_ inmm/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
Quoted 7 lines · Alan Cox
Quoted 4 lines
The sepearate one is horrible maintaince wise. Please introduce
CONFIG_MMUand try to make as many _files_ inmm/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.
Quoted 2 lines · Christoph Hellwig
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
Quoted 7 lines · Alan Cox
Quoted 2 lines · Christoph Hellwig
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
Quoted 9 lines · Alan Cox
Quoted 2 lines · Christoph Hellwig
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: www.SnapGear.com
Quoted 7 lines · Christoph Hellwig
Quoted 2 lines · Alan Cox
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
Signature · 4 lines
A: No. Q: Should I include quotations after my reply? http://www.surriel.com/ http://distro.conectiva.com/
Hi Rik,
Quoted 14 lines · Rik van Riel
Quoted 8 lines · Christoph Hellwig
Quoted 2 lines · Alan Cox
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:
Quoted 8 lines
1) the common stuff
2) the MMU stuff
3) the NOMMU stuff... and some magic in
Makefileto 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: www.SnapGear.com
Quoted 4 lines · Greg Ungerer
Rik van Riel wrote:
Easy done. Would it bother anyone having a few files named
XYZ-nommu.cin there?
Excellent.
Quoted 2 lines
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
Signature · 5 lines
Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: [email protected] [email protected]