Re: New linux arch
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 , an example where you should do it is . 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 <>< -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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.8Mdavem/net-2.6.25.git -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New linux arch
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 :-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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.8Mdavem/net-2.6.25.git -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New linux arch
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
