On 2/2/07, Ulf Samuelsson ulf@atmel.com wrote:
Then adding patches for the ARM926 based cpu/board directories, but without any references to these patches in Makefiles/MAKEALL. At the end a patch which would make them buildable.
No. Each patch is supposed to be independent of the others. It should be possible to apply only the first N patches of your sequenbce and get a useful, buildable code version - otherwise you will always have to rework the whole sequence if patch N+1 gets rejected for a reason or another.
What I mean is that I want to start with creating the cpu/arm926ejs/at91sam926x directory and associated includes. All the AT91SAM926x boards use this. Before the boardpatches are submitted, this will be a dangling patch since no board depends on it.
I think this makes sense. Adding support for a CPU is one logical change. If it gets used by a board patch later in the series, what's the problem?
Combining it with a board patch means that the series will have to be reworked if either of them changes. And it becomes very difficult to obey the size restrictions.
It will be a little easier to do the board patches if the cpu support is there.
Exactly.
But all this is documented in the README.
A bit OT: Would it make sense to split up the README a bit? For example, pull the patch submission rules out and put it into doc/SubmittingPatches or something? Similarly with the coding style rules and the CONFIG/CFG macro documentation. I think this would make it easier for everyone to get an overview of what documentation is really available and maybe more people would actually read the rules?
This would during a short period give some "dangling" or unused code I know you don't like that, so how proceed with such a large patchset, where things depend on each other?
Split it in orthogonal chunks. That's what they do with Linux, and what we have been doing with U-Boot for a long, long time.
I think board and cpu support _are_ two orthogonal chunks.
I dont have any git server which I can use for this.
You don't need a git server. Use a local repositoy, and git to create the patches.
I was thinking of the problem of size. The AT91SAM9263 header > 40 kB bzip2 compressed.
A header file (or really any single files) which weighs in at more than 40k compressed is just wrong. The at91 u-boot people need to talk more with the Linux people -- the at91 Linux headers are a lot more sane.
Register definitions for specific hardware modules should be split out into separate files IMO. For example, the USART definitions are redundant with drivers/atmel_usart.h anyway.
I think we should become better at collaborating on u-boot drivers between the avr32 and arm departments in Atmel. We're already doing this with Linux -- several drivers are already shared between avr32 and at91, e.g. atmel_serial and atmel_spi (which I'm hoping will go in during the 2.6.21 merge window.) I'll try to contact whoever is in charge of u-boot in the at91 departement and see if I can get the ball rolling on a joint effort to consolidate some of the at91 and avr32 stuff.
I assumed that if I use a git from where people can pull I can have larger patches, but that might be a mistake.
I think the size of the patches is more of an indicator that something is wrong. But I also think that if an oversize patch is otherwise ok we shouldn't let the size rule block it iff the coding style rules and the rule about single logical changes are being followed.
In Linux, oversize patches are usually posted at a public webserver with a link to it in the e-mail unless they have been fully reviewed and are sent to Linus for inclusion (without Cc to lkml.)
Btw, I don't really have anything to do with arm or at91, so feel free to ignore my advise.
Haavard