Hi all,
I redesigned all files for microblaze cpu (xilinx fpga).
All code is FDT compatible.
I would like to ask you what is the best way to push these changes to
kernel.org.
I would like to know step by step how to do.
I have some question about.
I have changes in my internal git repository. I don't have public git
repository.
Is it possible to create git repository in git.kernel.org for Microblaze
cpu?
What are maintainers responsibilities? Do you have any page about?
I am U-BOOT maintainer at denx.de and I hope that the responsibilities
will be similar.
How many maintainers are acceptable? (one or more)
I checked whole code with checkpatch.pl script to avoid code violations.
I hope I resolve the most of coding style problems.
I see the right way to push all changes to public git repository and
then send patches in small logical group to LKML with CC to people from
microblaze community.
And then wait for comments from you, solve problems, update git
repository and send changes again.
Thanks for your comments.
Cheers,
Michal Simek
On Mon, Jan 07, 2008 at 09:29:40PM +1000, Michal Simek wrote:
> Hi all,
>
> I redesigned all files for microblaze cpu (xilinx fpga).
> All code is FDT compatible.
Hi Michal.
It this code drop available somewhere?
I would like to review the Makefiles and to a lesser extent
the Kconfig files.
I could wait until I see patches on lkml - but why wait..
Sam
Hi Michael,
On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
> Is it possible to create git repository in git.kernel.org for Microblaze
> cpu?
You need to ask the kernel.org administrators for that:
http://www.kernel.org/faq/#account
On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
> What are maintainers responsibilities? Do you have any page about?
> I am U-BOOT maintainer at denx.de and I hope that the responsibilities
> will be similar.
>
> How many maintainers are acceptable? (one or more)
You can have as many maintainers as you want but you probably don't
want to make it too many. There aren't any "official" responsibilities
as a maintainer, it really depends on how much time and effort you're
willing to put in.
On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
> I see the right way to push all changes to public git repository and
> then send patches in small logical group to LKML with CC to people from
> microblaze community.
>
> And then wait for comments from you, solve problems, update git
> repository and send changes again.
You don't necessarily need a public git repository before sending your
patches to LKML but yeah, you definitely want some public exposure
before asking for Linus/Andrew to merge your port.
Pekka
Hi Sam,
> It this code drop available somewhere?
the code is based on Petalogix kernel. I reduce huge Kconfig file to
necessary size. You'll see in patch or in web.
A brief information about this kernel is at http://www.monstr.eu/fdt/
> I would like to review the Makefiles and to a lesser extent
> the Kconfig files.
I will add you to CC at Makefile and Kconfig patches.
Michal Simek
Hi Pekka,
>> Is it possible to create git repository in git.kernel.org for Microblaze
>> cpu?
>
> You need to ask the kernel.org administrators for that:
>
> http://www.kernel.org/faq/#account
Thanks.
>> How many maintainers are acceptable? (one or more)
>
> You can have as many maintainers as you want but you probably don't
> want to make it too many. There aren't any "official" responsibilities
> as a maintainer, it really depends on how much time and effort you're
> willing to put in.
OK. Don't you have idea how many linux kernels are maintained by more
people?
> You don't necessarily need a public git repository before sending your
> patches to LKML but yeah, you definitely want some public exposure
> before asking for Linus/Andrew to merge your port.
Yes.
Michal Simek
Hi Michal,
On Jan 7, 2008 3:00 PM, Michal Simek <[email protected]> wrote:
> > You can have as many maintainers as you want but you probably don't
> > want to make it too many. There aren't any "official" responsibilities
> > as a maintainer, it really depends on how much time and effort you're
> > willing to put in.
>
> OK. Don't you have idea how many linux kernels are maintained by more
> people?
Well, just look up some mainstream architectures in MAINTAINERS. The
x86 architecture, for example, has three but the point here is that
you probably don't want to end up with ten individual maintainers (how
are you going to coordinate the work?) whereas more than one is
definitely okay.
If you have a lot of people maintaining your port, then just create a
mailing list and put that in MAINTAINERS with only few "top
maintainers" listed by their individual email to make life easy for
patch submitters.
Pekka
On Jan 7 2008 14:47, Pekka Enberg wrote:
>Hi Michael,
>
>On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
>> Is it possible to create git repository in git.kernel.org for Microblaze
>> cpu?
>
>You need to ask the kernel.org administrators for that:
>
> http://www.kernel.org/faq/#account
Alternatively, providing your own git service is just as effective,
and comes with much more freedom :)
Jan Engelhardt wrote:
>>On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
>>> Is it possible to create git repository in git.kernel.org for Microblaze
>>> cpu?
...
> Alternatively, providing your own git service is just as effective,
> and comes with much more freedom :)
It is /almost/ as effective:
- Many of the git trees on kernel.org are set up to share objects with
Linus' tree.
- The tree owners can fetch from each other locally and via ssh:
protocol, alternatively to the remote protocols.
But it is exactly as effective in terms of the workflow organization.
--
Stefan Richter
-=====-==--- ---= --===
http://arcgraph.de/sr/
On Jan 7 2008 18:26, Stefan Richter wrote:
>Jan Engelhardt wrote:
>>>On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
>>>> Is it possible to create git repository in git.kernel.org for Microblaze
>>>> cpu?
>...
>> Alternatively, providing your own git service is just as effective,
>> and comes with much more freedom :)
>
>It is /almost/ as effective:
> - Many of the git trees on kernel.org are set up to share objects with
>Linus' tree.
Oh? So `du -s davem/net-2.6.25` will not be like 170 megs in size?
> - The tree owners can fetch from each other locally and via ssh:
>protocol, alternatively to the remote protocols.
For bandwidth-savers, yeah. For those who have the pipe, time, money
or devotion, pulling from torvalds/linux-2.6.git is enough, and it will be
pushed out with the next set of development changesets anyway :-)
Jan Engelhardt wrote:
> On Jan 7 2008 18:26, Stefan Richter wrote:
>> Jan Engelhardt wrote:
>>>> On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
>>>>> Is it possible to create git repository in git.kernel.org for Microblaze
>>>>> cpu?
>> ...
>>> Alternatively, providing your own git service is just as effective,
>>> and comes with much more freedom :)
>> It is /almost/ as effective:
>> - Many of the git trees on kernel.org are set up to share objects with
>> Linus' tree.
>
> Oh? So `du -s davem/net-2.6.25` will not be like 170 megs in size?
>
Nope:
: hera 9 ; du -sh davem/net-2.6.25.git
8.8M davem/net-2.6.25.git
-hpa
Pekka Enberg wrote:
> On Jan 7, 2008 1:29 PM, Michal Simek <[email protected]> wrote:
>> How many maintainers are acceptable? (one or more)
>
> You can have as many maintainers as you want but you probably don't
> want to make it too many.
Bug reporters and patch submitters shouldn't be required to CC too many
addresses.
>> I see the right way to push all changes to public git repository and
>> then send patches in small logical group to LKML with CC to people from
>> microblaze community.
>>
>> And then wait for comments from you, solve problems, update git
>> repository and send changes again.
>
> You don't necessarily need a public git repository before sending your
> patches to LKML but yeah, you definitely want some public exposure
> before asking for Linus/Andrew to merge your port.
Yes, patch review is always done on the mailing list(s). Not only
during the initial submission, but also for all later changes.
A git repository provided by you could be used
- by interested people to fetch your pre-integrated development
sources,
- by Andrew Morton to pull into -mm. This needs to be a branch in
your repo which only contains stuff which works to the best of your
knowledge, i.e. is already tested and got at least some basic review
by those involved in the subproject. It always has to give a clean
and working diff against Linus' current tree, because that's what
Andrew bases -mm on. (This means you have to rebase or otherwise
update this branch whenever there were conflicting changes in Linus'
tree.) Also, if you need to do changes outside your subsystem,
coordinate it with the tree owners of the other subsystems to
minimize conflicts when Andrew assembles -mm.
Alternatively to git, you could also work with Andrew via a quilt
tree or via e-mail, depending on what turns out as most effective.
- by Linus to pull into his tree if he thinks he can work with your
tree better than via e-mail. Regardless if git or e-mail, you are
of course supposed to only offer stuff to Linus which is known to
work and has been fully reviewed.
New work (feature additions or removals, refactoring, intrusive bug
fixes) needs to be sent to Linus early before an -rc1 release.
Between -rc1 and -final, only bug fixes are acceptable. (In early
-rc's maybe also a few other small nonintrusive changes that can't
possibly break anything...)
Note, everything which I said here only reflects what I remember as
required or most desirable; it's not a canonical list of requirements.
Anyway, it may be a little bit too early to think about those things
before you posted your initial submission for review and re-review...
--
Stefan Richter
-=====-==--- ---= --===
http://arcgraph.de/sr/
On Mon, Jan 07, 2008 at 10:51:40PM +1000, Michal Simek wrote:
> Hi Sam,
>
> > It this code drop available somewhere?
>
> the code is based on Petalogix kernel. I reduce huge Kconfig file to
> necessary size. You'll see in patch or in web.
>
> A brief information about this kernel is at http://www.monstr.eu/fdt/
>
> > I would like to review the Makefiles and to a lesser extent
> > the Kconfig files.
>
> I will add you to CC at Makefile and Kconfig patches.
I did not find the kernel source at first look.
Will await your patch submissions and then
review it.
Sam
On Mon, 2008-01-07 at 21:29 +1000, Michal Simek wrote:
> Hi all,
>
> I redesigned all files for microblaze cpu (xilinx fpga).
> All code is FDT compatible.
For those who don't know, FDT is the flattened device-tree format used
nowadays on PowerPC, based on the open firmware device-tree.
I'm really happy to see that being picked up by another architecture,
that's great !
Cheers,
Ben.
Hi Ben,
>> I redesigned all files for microblaze cpu (xilinx fpga).
>> All code is FDT compatible.
>
> For those who don't know, FDT is the flattened device-tree format used
> nowadays on PowerPC, based on the open firmware device-tree.
>
> I'm really happy to see that being picked up by another architecture,
> that's great !
:-) Plus for embedded Xilinx FPGA cpu - PPC405 and Microblaze you can
generate DTS file from EDK project.
Michal Simek
On Jan 7, 2008 7:29 PM, Michal Simek <[email protected]> wrote:
> Hi all,
>
> I redesigned all files for microblaze cpu (xilinx fpga).
> All code is FDT compatible.
>
> I would like to ask you what is the best way to push these changes to
> kernel.org.
>
Welcome to the home of kernel.
I remember Blackfin maybe is the most recently new arch accept by
kernel mainline. So maybe some information can be shared with you
guys.
> I would like to know step by step how to do.
>
1. Push patches to LKML when merge window open (2 weeks after a stable
kernel version release, for example 2 weeks after 2.6.24 released)
2. Patches will be reviewed by kernel gurus and please update your
patches according to their comments. (It will take some time to get
ack from them -:)) ).
3. Reviewed patches will be accept to -mm tree by Andrew. (And please
do development and updates based on -mm tree)
4. After one or more development cycle, the patches will be sent to
Linus to merge into mainline kernel at another merge window.
5. Use GIT to maintain the Microblaze subsystem development and you
can apply an account on kernel.org. Then setup a public GIT tree for
Linus pull and development.
> I have some question about.
>
> I have changes in my internal git repository. I don't have public git
> repository.
> Is it possible to create git repository in git.kernel.org for Microblaze
> cpu?
>
Currently no need public git tree, after it is merged into mainline,
you can apply one for maintaining and development.
> What are maintainers responsibilities? Do you have any page about?
> I am U-BOOT maintainer at denx.de and I hope that the responsibilities
> will be similar.
>
IMO, maintainer of one subsystem should review all the patches related
your subsystem,
test the patches at real hardware, fix bugs and send them to upstream
mainline at the right time.
> How many maintainers are acceptable? (one or more)
>
It depends on your internal development style. There is a team in
Analog Devices for Blackfin Linux development.
But I am responsible for kernel maintaining currently.
> I checked whole code with checkpatch.pl script to avoid code violations.
> I hope I resolve the most of coding style problems.
>
Yes, passing checkpatch.pl is required by LKML.
> I see the right way to push all changes to public git repository and
> then send patches in small logical group to LKML with CC to people from
> microblaze community.
>
No, please send out all your patches to LKML and CC to Microblaze world.
People from LKML will review your patches.
> And then wait for comments from you, solve problems, update git
> repository and send changes again.
>
No. update your patches and send the patches to LKML again.
GIT pull is only validated after your patches are in mainline.
Thanks
Regards,
-Bryan Wu
Hi Bryan,
On Jan 8, 2008 10:28 AM, Bryan Wu <[email protected]> wrote:
> 1. Push patches to LKML when merge window open (2 weeks after a stable
> kernel version release, for example 2 weeks after 2.6.24 released)
You shouldn't wait for the merge window to open to send patches for
review for the first time; otherwise you'll just miss the opportunity
to merge ;-).
Pekka
On Jan 8, 2008 4:49 PM, Pekka Enberg <[email protected]> wrote:
> Hi Bryan,
>
> On Jan 8, 2008 10:28 AM, Bryan Wu <[email protected]> wrote:
> > 1. Push patches to LKML when merge window open (2 weeks after a stable
> > kernel version release, for example 2 weeks after 2.6.24 released)
>
> You shouldn't wait for the merge window to open to send patches for
> review for the first time; otherwise you'll just miss the opportunity
> to merge ;-).
>
Really? I was told before to send out big patch to LKML for the merge window.
If not, it's good news for Michal and MicroBlaze guys.
Thanks
-Bryan Wu
Bryan Wu wrote:
> On Jan 8, 2008 4:49 PM, Pekka Enberg <[email protected]> wrote:
>> On Jan 8, 2008 10:28 AM, Bryan Wu <[email protected]> wrote:
>> > 1. Push patches to LKML when merge window open (2 weeks after a stable
>> > kernel version release, for example 2 weeks after 2.6.24 released)
>>
>> You shouldn't wait for the merge window to open to send patches for
>> review for the first time; otherwise you'll just miss the opportunity
>> to merge ;-).
>>
>
> Really? I was told before to send out big patch to LKML for the merge window.
> If not, it's good news for Michal and MicroBlaze guys.
There aren't any fixed windows for development, review, testing, and so
on. There is only Linus' merge window for the merge process of the
patches that have been reviewed, tested, and pre-integrated.
Of course people like akpm and the maintainers of the larger subsystems
necessarily align their own work with Linus', therefore there may be
periods around merge windows during which relevant people won't
integrate larger submissions. But that does not mean you could not post
them.
--
Stefan Richter
-=====-==--- ---= -=---
http://arcgraph.de/sr/
Bryan Wu wrote:
> On Jan 7, 2008 7:29 PM, Michal Simek <[email protected]> wrote:
>> I checked whole code with checkpatch.pl script to avoid code violations.
>> I hope I resolve the most of coding style problems.
>
> Yes, passing checkpatch.pl is required by LKML.
checkpatch.pl only gives guidance; it is not a hard requirement. You
should have good reasons if you deviate from it though.
Also check with sparse (Documentation/sparse.txt). And there is much
more you should have a look at before you send proposed patches, see
Documentation/SubmitChecklist.
--
Stefan Richter
-=====-==--- ---= -=---
http://arcgraph.de/sr/
On Monday 07 January 2008, Michal Simek wrote:
> I would like to ask you what is the best way to push these changes to
> kernel.org.
>
> I would like to know step by step how to do.
>
Adding the whole architecture tree will probably be too much for
a single reviewer and almost certainly too much for a the size limit
of mails to lkml.
On the other hand, there is not much point in merging the architecture
code in multiple changesets if there is nothing at all you can do
with part of it. I suggest therefore that you split the code twice:
First, split every device driver into its own git changeset. Often,
these have to go through a different set of mailing lists, e.g.
network drivers go to [email protected] (see MAINTAINERS for
details), while the actual architecture changeset should not have
device drivers by itself. These are going to be the changesets
that you have in your git tree and merged upstream eventually.
Then, split each of those changesets into reviewer-friendly
chunks of less than 100kb. Don't worry if a patch ends up only having
a few line while others are considerably larger.
For people that like to see a whole changeset, upload it as a combined
patch to an http location that you mention in your patch 00/12 or so,
and have the smaller patches as reply mails to that.
Use either 'quilt mail' or 'git-format-patch' to do that work for you.
I think blackfin is a good example of how an architecture got merged,
and how they resolved the initial problems. Read through the comments
at http://lkml.org/lkml/2006/9/20/404 and related mails to see what
can go wrong in such large projects and how to do it better.
Regarding the code itself, my assumption is that you started out
copying from another architecture (everyone does that) and hacked on
it until you had it working. This is not wrong by itself, but it would
be really nice if we can make it easier for the next person to
add an architecture. My vision is that for each header file you
copied from include/asm-i386 or similar and did not end up rewriting,
you create a version in include/asm-generic and start using that
instead of adding a private copy in your architecture.
One example where this was already done is <asm/errno.h>, an example
where you should do it is <asm/stat.h>.
It's similar for files like arch/microblaze/kernel/sys.c and pci.c:
ideally, you shouldn't have these at all, but be able to just
use completely generic code.
Arnd <><