Menu
▾
▴
linuxsh-dev
|
From: Jeremy S. <js...@mv...> - 2001-12-04 18:45:00
|
Hi folks, Trying to keep the drop-in trees easy to drop in, over the last several days I've updated the 2.4 branch to 2.4.16 and the 2.5 branch to 2.5.0; before modifying the 2.4 branch I retagged it linux-2.4.13-pre2, so you can pull the old one with that tag. However: I only tested minimal SH3/SH4 Solution Engine platforms, so other things may have broken (e.g. Robert Love already submitted a fix for the gdrom, which apparently didn't even compile.) In a couple cases, diffs to the SH tree conflicted with generic kernel changes and they may not be correct now; those more familiar with these specific portions of code may want to take a look at them... drivers/net/8139too.c: Most SH changes (buffer size and DMA for Dreamcast) carried forward, except for the last one in rtl8139_start_xmit(), where USE_NO_DMAMAP forced an skb_copy_and_csum_dev() call. The copy is now done all the time, so there was nowhere to put that check; I assume that's ok? (Come to think of it, that means USE_NO_DMAMAP could be removed.) mm/memory.c: There were two places where the SH code ifdef'd out cache flush calls for performance, noting in comments that a VIPT cache doesn't require them. The second of these was in do_wp_page(), and the code changed enough that I chose NOT to ifdef out that flush call, since I wasn't sure if the conditions that made it unnecessary still applied. The other places where SH tweaks common code is a few insertions of cache flush calls; include/linux/highmem.h:memclear_highpage_flush() and kernel/ptrace.c:access_one_page() both add flush_dcache_page(page) right before flush_page_to_ram(page). And drivers/block/rd.c:initrd_read() adds flush_cache_all() right after a copy_to_user() call. I left all these alone, assuming they're still necessary (cache aliasing issue?) but Niibe may want them removed if they're no longer necessary? --Jeremy Siegel |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-05 01:40:13
|
Here's a patch.
2001-12-05 NIIBE Yutaka <gn...@m1...>
* mm/memory.c (do_wp_page): Re-introduce ifdef-out-ing
flush_cache_page.
Index: mm/memory.c
===================================================================
RCS file: /cvsroot/linuxsh/linux/mm/memory.c,v
retrieving revision 1.2
diff -u -3 -p -r1.2 memory.c
--- mm/memory.c 2001/12/03 22:15:35 1.2
+++ mm/memory.c 2001/12/05 01:38:12
@@ -917,7 +917,9 @@ static int do_wp_page(struct mm_struct *
int reuse = can_share_swap_page(old_page);
unlock_page(old_page);
if (reuse) {
+#if 0 /* This is not needed for VIPT cache, performance goes bad if we flush */
flush_cache_page(vma, address);
+#endif
establish_pte(vma, address, page_table, pte_mkyoung(pte_mkdirty(pte_mkwrite(pte))));
spin_unlock(&mm->page_table_lock);
return 1; /* Minor fault */
--
|
|
From: Robert L. <rm...@te...> - 2001-12-05 03:09:52
|
On Tue, 2001-12-04 at 20:40, NIIBE Yutaka wrote:
> +#if 0 /* This is not needed for VIPT cache, performance goes bad if we flush */
> flush_cache_page(vma, address);
> +#endif
For multiple reasons, shouldn't we do this:
+#if !defined(CONFIG_SUPERH) /* this is not needed for VIPT cache */
flush_cache_page(vma, address);
+#endif
instead ?
Robert Love
|
|
From: David W. <dw...@in...> - 2001-12-05 08:33:22
|
> +#if !defined(CONFIG_SUPERH) /* this is not needed for VIPT cache */ > flush_cache_page(vma, address); > +#endif Could there possibly be a more graphic demonstration of just how horribly stupid and broken the existing Linux cache management API currently is? The fact that some architectures actually achieve what you're trying to do here by making flush_cache_page() a NOP doesn't help make things better, either :) 2.5 has opened. I think it's time to provide an API to the cache code that actually makes sense, and the functions bear some relation to their behaviour and the reasons for calling them. Hint: Generic code, which knows nothing about how the CPU's cache works, almost never actually _needs_ to flush a page. It normally only wants to make sure there are no aliases with other virtual addresses in the dcache, or that code newly written through the dcache is present in the icache. Hence, the word 'flush' should no appear in the names of functions called from generic code. So contemplate how sane it would be to have functions called unalias_dcache_page_ram, unalias_dcache_page_icache, or something vaguely representing the actual behaviour - then it's perfectly OK to have some of them do nothing, and you can far more easily make sure the right ones are called at the right times, and do the right things. We really shouldn't need arch-specific ifdefs like that in common code. -- dwmw2 |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-05 08:37:52
|
David Woodhouse wrote: > 2.5 has opened. I think it's time to provide an API to the cache code that > actually makes sense, and the functions bear some relation to their > behaviour and the reasons for calling them. Yes, that is my point too. Leave ugly thing as is so that people want to do better one. This treatment is the note for our project. -- |
|
From: David W. <dw...@in...> - 2001-12-05 11:28:11
|
js...@mv... said: > Trying to keep the drop-in trees easy to drop in, over the last > several days I've updated the 2.4 branch to 2.4.16 and the 2.5 branch > to 2.5.0; before modifying the 2.4 branch I retagged it > linux-2.4.13-pre2, so you can pull the old one with that tag. Much stuff is still including <asm/segment.h>. We should send Linus/Marcelo a patch which removes that include from anything but arch-specific code. It shouldn't be required. -- dwmw2 |
|
From: M. R. B. <mr...@0x...> - 2001-12-07 04:15:57
|
* NIIBE Yutaka <gn...@m1...> on Fri, Dec 07, 2001: >=20 > I don't say, we should encourage incompatibility or divergent tree. I > said, we have to think about maintaining the divergence. Although we > should do our best to minimize the divergence, there _is_ always > divergence and it is quite important to maintain the divergence and > merging. >=20 Yes, today there is divergence. But it doesn't have to always be this way. I'm proposing that we become much more agressive in sending patches against mainline to their respective maintainters, and Marcelo and Linus. We don't have any excuse not to. If a patch is desperately needed (I can hear Greg and Stuart talking about a PCMCIA patch) and the maintainer of that code remains unresponsive, then send it to Marcelo or Linus CC'd to the maintainer and lkml. This way everyone gets to see it, and even if it still doesn't go in people can fix it on their own. We have to up the ante, we shouldn't just blindly accept breakage from up high. > It takes time to do the merging, and since the band width (of human > being) is limited resource, we should be careful to do the merging. >=20 Not if we stay in sync on a regular basis. Even still, there's now incremental pre- patches on kernel.org, so syncing from older versions should be much easier. As far as limited resource, you've just been offered help to do the merging work. What's wrong with Robert doing a merge and posting it here before it gets sent to Linus? Being the maintainer, you can easily review and approve/decline the patch as necessary .. do you have any objections to that? >=20 > Yes. You did good job towards this goal. Don't you think that part > of mm/memory.c is maintained by me? >=20 [...] > Because I maintain this divergence of mm/memory.c. Obviously, it's > ugly hack, but it's important for performance wise for SuperH or other > relevant architecture. We need API change for cache handling routines > for merge, but for a while it's good. It's definitely _not_ > CONFIG_SUPERH thing. For me, it looks quite selfish and bad code for > generic part of kernel to have CONFIG_SUPERH if it's not really > needed. >=20 If it only applies to SuperH then it is a CONFIG_SUPERH thing. CONFIG_* options are specific to what they define, if they weren't, would we have CONFIG_SH_DREAMCAST sprinkled all over drivers/net/8139too.c ? If something needs to be changed in mainline for our port to work, then we need to change it, just as you've been sending patches to fix gcc, this is the same idea. >=20 > It's good tools. But unfortunately, it's not perfect. If some part > is not going in, then, he has divergence in his working tree, isn't > it? >=20 Yes, for awhile. I'm saying we should cut that time short, and *not* have stale code that could've went into mainline (or been fixed) sitting around for a year or so. >=20 > I have been doing that. I don't think other person sending patches > help things here. Say, do you believe RedHat users who find > divergence between mainline and the kernel distributed by RedHat > sending the difference to Linus? I don't think so. >=20 We're not just users, we're developers. Red Hat users don't submit kernel patches to Red Hat, Red Hat has it's own kernel development team that maintains its patches, just as you and I and Paul and Jeremy maintain parts of the LinuxSH tree. So your analogy doesn't hold here. And yeah, if someone has a problem in our area of code, then we should be the ones to respond, just like Red Hat is responsible for tracking support for it's code. Oh, and you haven't been regularly sending patches to Linus, else we wouldn't be having this discussion! >=20 > For me, 2.5 thing is better to follow. 2.4 is difficult. I don't want to go back and forth (and I'm sure you don't), so I'll just say this - help is being offered to ease your workload. The communication lines are open, and you have some experienced kernel hackers that are willing to give you assistance. If the situation occurs where it takes too long for changes to be accepted and/or passed back to Linus, then you'll eventually end up with the same sort of "fork" that happened with SGI OSS and linux-mips. Ask those developers why they chose to open another tree. M. R. |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-07 04:44:45
|
M. R. Brown wrote: > Yes, today there is divergence. But it doesn't have to always be this way. > I'm proposing that we become much more agressive in sending patches against > mainline to their respective maintainters, and Marcelo and Linus. We don't > have any excuse not to. If a patch is desperately needed (I can hear Greg > and Stuart talking about a PCMCIA patch) and the maintainer of that code > remains unresponsive, then send it to Marcelo or Linus CC'd to the > maintainer and lkml. This way everyone gets to see it, and even if it > still doesn't go in people can fix it on their own. I see your point here. I agree. > Not if we stay in sync on a regular basis. Even still, there's now > incremental pre- patches on kernel.org, so syncing from older versions > should be much easier. As far as limited resource, you've just been > offered help to do the merging work. What's wrong with Robert doing a > merge and posting it here before it gets sent to Linus? Being the > maintainer, you can easily review and approve/decline the patch as > necessary .. do you have any objections to that? OK, I see your point. I agree this point. I've confused that you have objection about the handling of mm/memory.c and I misunderstood sending #ifdef CONFIG_SUPERH version to main line were the solution. Here, we have two issues, specific one for mm/memory.c and general LinuxSH work. For latter, thanks for your proposal and others, I think that it's reasonable. Note that there is some divergence (though we should minimize it) that should _not_ be sent to mainline, and should leave local... please read on. For mm/memory.c, I think that this divergence is needed (at least for me), because I do this cache handling work and I think that it is not good thing to send it to mainline. So, I ask you or others not to send it to mainline and not change it as if it's done (CONFIG_SUPERH). It is intentional. It is the my local signature, where we should think about better solution but for a while, work around. It is no thank you for me, to do some cosmetic change and then to send it mainline. I hope you understand this point. > If it only applies to SuperH then it is a CONFIG_SUPERH thing. No, it's not only SuperH. The change should go API. See other API of cache handling routines. Same API and different implementation, instead of having many #ifdef CONFIG_* thing in the code. We cannot just nullify flush_cache_page, because other usage of flush_cache_page is valid. Well, the work is something like this: We need to distingush the cases, and would define flush_cache_page_SOMETING and replace the occurrence (currently #if0-outed) of flush_cache_page in to flush_cache_page_SOMETING. We need to check the API change is good and clean for other archtecture. If it's good for the generic part of kernel and a like... Please read David Woodhouse's comment. -- |
|
From: Robert L. <rm...@te...> - 2001-12-10 04:07:19
|
On Sun, 2001-12-09 at 19:35, NIIBE Yutaka wrote: > For mm/memory.c, I think this is good. Official tree works anyway, though > runs with bad performance. True. > No, I don't. While I disagreed the handling of mm/memory.c, but I agree > that we should think and act for the synch to mainline. Good. > > Please consider the suggestions above. Let's synchronize things as much > > as possible. > > Yes. > > My plan for this week is like following: > (1) Check the patches I hold, and check in to the repository: > big-endian bug for users.h > discontigous memory handling > configuration issues (i.e., config.in and config.help) > (2) Check the difference between 2.4 and repository > and send it to upstream. > (3) Check the difference between 2.5 and repository > and send it to upstream. > (4) Gather opinion and features for 2.5 > > For (2) or (3) I think that I will submit the difference to this list > before sending to upstream, so that people can see what's going on > more clearly. Please note that I don't send all the difference, and > sometimes some parts may not be included by the upstream maintainer. Excellent! I'll be happy to help if needed; just let me know. > For (4), keeping up to kbuild is major one. > > I have a question to M.R. How do you think about the drivers for DC? > Is it ready for inclusion of mainline? I don't know 2.4 opens for new > drivers or not, but at least it's worth sending those to 2.5. He is not me, but the DC drivers seem very solid. 2.4 _is) taking new drivers so you can send those off. We actually have a better chance of getting the 2.4 merge synced ... 2.5 may take longer. Robert Love |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 07:01:20
|
Robert Love wrote: > I'll be happy to help if needed; just let me know. Could you please write-up some sort of a page of "divergence status"? You see, some part is pending, some part is just a work around, some part is ready to submit. Each developers knows the things for himself, but it would be good if the information is available for other person. -- |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-11 06:27:38
|
NIIBE Yutaka wrote:
> Besides, following files are meaningless without those files.
^^^^^ changes
> Makefile
> driver/cdrom/Config.in
> driver/cdrom/Makefile
> driver/char/Makefile
> driver/char/joystic/Config.in
> driver/char/joystic/Makefile
> include/linux/input.h
and
init/main.c
For the addition of include/asm-sh/segment.h, IIRC, our conclusion
was: have it in our tree for convenience, but not send it to mainline
because the it has been obsolete for seven years or so.
--
|
|
From: NIIBE Y. <gn...@m1...> - 2001-12-05 00:54:03
|
Jeremy Siegel wrote: > drivers/net/8139too.c: Will look into. > mm/memory.c: > There were two places where the SH code ifdef'd out cache flush calls > for performance, noting in comments that a VIPT cache doesn't require > them. The second of these was in do_wp_page(), and the code changed > enough that I chose NOT to ifdef out that flush call, since I wasn't > sure if the conditions that made it unnecessary still applied. VIPT: Virtually Indexed Phisically Tagged cache. For break_cow, we don't need to flush the cache. On some architecture where permission informatipn is there, we need to flush it because it was read-only before. But it's not the case for SuperH. If you want, please try to enable the flushing and see how the performance going down. For the case of do_wp_page, I think conditions still are applied. The logic is same as break_cow. On some architecture (not SuperH), it is needed, or else, the fault occurs again and again. > The other places where SH tweaks common code is a few insertions of > cache flush calls; include/linux/highmem.h:memclear_highpage_flush() and > kernel/ptrace.c:access_one_page() both add flush_dcache_page(page) right > before flush_page_to_ram(page). And drivers/block/rd.c:initrd_read() > adds flush_cache_all() right after a copy_to_user() call. I left all > these alone, assuming they're still necessary (cache aliasing issue?) > but Niibe may want them removed if they're no longer necessary? Those are paranoia things which can be removed. -- |
|
From: Jeremy S. <js...@mv...> - 2001-12-05 18:03:31
|
NIIBE Yutaka wrote: > VIPT: Virtually Indexed Phisically Tagged cache. > > For break_cow, we don't need to flush the cache. On some architecture > where permission informatipn is there, we need to flush it because it > was read-only before. But it's not the case for SuperH. If you want, > please try to enable the flushing and see how the performance going > down. > > For the case of do_wp_page, I think conditions still are applied. The > logic is same as break_cow. On some architecture (not SuperH), it is > needed, or else, the fault occurs again and again. Thanks -- since I don't know enough about the memory management the change from exclusive_swap_page() and delete_from_swap_cache() to can_share_swap_page() made me wonder, but if you say it's still safe, I'm quite happy to remove it as per your patch! Robert Love wrote: > For multiple reasons, shouldn't we do this: > > +#if !defined(CONFIG_SUPERH) /* this is not needed for VIPT cache */ > flush_cache_page(vma, address); > +#endif We'd do it that way in anything we distribute from mvista, of course, but in the community tree I'd want to defer to the community. However... NIIBE Yutaka wrote: > David Woodhouse wrote: > > 2.5 has opened. I think it's time to provide an API to the cache code that > > actually makes sense, and the functions bear some relation to their > > behaviour and the reasons for calling them. > > Yes, that is my point too. Leave ugly thing as is so that people want > to do better one. ...I think that to encourage a general API rewrite the ugliness has to be in the kernel.org tree; if it's only in the linuxsh tree only we will care. If I had to compare #if 0 and #ifndef CONFIG_SUPERH I'd guess the latter would be more likely to be accepted. (I know it's generally frowned upon anyway, but it might get someone thinking; the #if 0 submission would probably be banned outright.) Another minor point: even in the linuxsh tree itself, using CONFIG helps make it clear that this is deliberate, and not leftover/experimental hackery. (Maybe that's one of the other "multiple reasons" Robert refers to;-) --Jeremy Siegel |
|
From: Robert L. <rm...@te...> - 2001-12-05 20:07:29
|
On Wed, 2001-12-05 at 13:03, Jeremy Siegel wrote: > ...I think that to encourage a general API rewrite the ugliness has to be in > the kernel.org tree; if it's only in the linuxsh tree only we will care. If > I had > to compare #if 0 and #ifndef CONFIG_SUPERH I'd guess the latter would > be more likely to be accepted. (I know it's generally frowned upon anyway, > but it might get someone thinking; the #if 0 submission would probably be > banned outright.) I think the #if !defined(CONFIG_SH) is still enough to show a rewrite is needed. We should really aim for no ifdefs in code if at all possible -- the function/define definitions should provide the conditional compiling. > Another minor point: even in the linuxsh tree itself, using CONFIG helps > make it clear that this is deliberate, and not leftover/experimental hackery. > (Maybe that's one of the other "multiple reasons" Robert refers to;-) Exactly. That is one reason. Another is that the #if 0 makes the tree instantly incompatible with any arch other than SH. The SH tree should be fully compatible with all arches, so that we can resync with each other. For instance, we can push the #if defined to the mainline kernel. We would have to wear a brown paper bag for a month if we sent the #if 0 off. Which brings me to the next point ... the trees are way out of sync. When was the last time someone pushed an SH merge off to the official kernel? Thankfully, Jeremy just merged official into SH but we need it the other way around now. I would be happy to put together a diff against the latest 2.4 and 2.5 and send it off to Marcelo and Linus for merging into their tree. I suspect it will take some work to make sure we keep the code correct (ie, nothing like the #if 0 stuff). I would want the maintainer's permission before I do this. Second, with 2.5 starting, we need conversion to both CML2 and kbuild-2.5. Both are non-trivial changes. The SH port is the _only_ piece of the kernel non-synced with CML2, supposedly at the maintainer's request that he do it? Also, SH items in Configure.help are very lacking. CML2 will _not_ allow an item to be selected if in non-expert mode if it has no configure help! And kbuild-2.5 will require a rewrite of our makefiles... I'm offering my help. Comments? Robert Love |
|
From: David W. <dw...@in...> - 2001-12-05 22:41:33
|
rm...@te... said:
> I think the #if !defined(CONFIG_SH) is still enough to show a rewrite
> is needed.
The thing that does it for me is finding crap like
#define flush_cache_range(mm, start, end) do { } while (0)
I tried to _use_ that for dealing with flash chip state changes - and it's
hardly surprising it didn't work, is it? :)
rm...@te... said:
> I would be happy to put together a diff against the latest 2.4 and 2.5
> and send it off to Marcelo and Linus for merging into their tree. I
> suspect it will take some work to make sure we keep the code correct
> (ie, nothing like the #if 0 stuff).
Actually, it's not that hairy. I've made such a patch already, for building
the Red Hat RPM kernel for SH. It's quite clean.
> Also, SH items in Configure.help are very lacking. CML2 will _not_
> allow an item to be selected if in non-expert mode if it has no
> configure help!
That is not an acceptable policy change. It will only go in if ESR sneaks it
in as part of the switch to the CML2 mechanism. If it's submitted
separately and honestly, so that it can be discussed individually, I'm sure
it won't get accepted.
But we ought to make the help text catch up anyway.
--
dwmw2
|
|
From: Robert L. <rm...@te...> - 2001-12-05 22:59:33
|
On Wed, 2001-12-05 at 17:41, David Woodhouse wrote:
> The thing that does it for me is finding crap like
> #define flush_cache_range(mm, start, end) do { } while (0)
>
> I tried to _use_ that for dealing with flash chip state changes - and it's
> hardly surprising it didn't work, is it? :)
I think the above is certainly better than having the ifdefs in the code
itself.
> Actually, it's not that hairy. I've made such a patch already, for building
> the Red Hat RPM kernel for SH. It's quite clean.
Ah, good. I'd like to see a merge with 2.4/2.5 mainstream, but I'd like
the maintainer's permission to start pushing bits.
> That is not an acceptable policy change. It will only go in if ESR sneaks it
> in as part of the switch to the CML2 mechanism. If it's submitted
> separately and honestly, so that it can be discussed individually, I'm sure
> it won't get accepted.
Good, I agree. I've said as much in the past, at least, about cml2.
Nonetheless, we need documentation. Even more important, the cml2
package is not synced to SH at all. Ie, it won't work. We need to fix
that (or not use cml2 <grin>).
Robert Love
|
|
From: David W. <dw...@in...> - 2001-12-05 23:08:12
|
rm...@te... said: > I think the above is certainly better than having the ifdefs in the > code itself. I disagree. Having a flush_cache_range() function which does _less_ than its name implies is a correctness problem. Having the per-arch ifdefs to optimise away the flushes which aren't necessary, ugly though it may be, it still better than that. Provide a new function with a name that at least vaguely describes its behaviour - and all will be well. > Nonetheless, we need documentation. Even more important, the cml2 > package is not synced to SH at all. Ie, it won't work. We need to > fix that (or not use cml2 <grin>). Surely we just need to make sure that our stuff is merged first? Then paint it pink :) -- dwmw2 |
|
From: Robert L. <rm...@te...> - 2001-12-05 23:12:28
|
On Wed, 2001-12-05 at 18:07, David Woodhouse wrote: > I disagree. Having a flush_cache_range() function which does _less_ than > its name implies is a correctness problem. Having the per-arch ifdefs to > optimise away the flushes which aren't necessary, ugly though it may be, it > still better than that. I _want_ per-arch definitions that optimize away the flushes that aren't needed! Code should be written for the common denominator, and if arch X doesn't need Y, then it defines to nothing. I think that is what you want, too? > Provide a new function with a name that at least vaguely describes its > behaviour - and all will be well. I agree here ... its how we handle the per-arch mess I am speaking of. > > Nonetheless, we need documentation. Even more important, the cml2 > > package is not synced to SH at all. Ie, it won't work. We need to > > fix that (or not use cml2 <grin>). > > Surely we just need to make sure that our stuff is merged first? Then paint > it pink :) I just talked to Marcelo about merging into 2.4 ... Robert Love |
|
From: Tom R. <tr...@ke...> - 2001-12-06 04:48:59
|
On Wed, Dec 05, 2001 at 03:06:34PM -0500, Robert Love wrote: > Which brings me to the next point ... the trees are way out of sync. > When was the last time someone pushed an SH merge off to the official > kernel? Thankfully, Jeremy just merged official into SH but we need it > the other way around now. Welcome to the !x86 world. :) (I'm almost sure you've had experiance with another arch, but for the rest of the world soon to be joining...) anything other than x86 will never be fully in sync anyhow. The fun part is idealy you sync up with a rev, pound it heavily and hope that upstream hasn't changed a lot in the mean time. Then you patch bomb. :) Having said that, do any of the powers that be have plans to being patchbombing marcelo (and maybe even linus? :)) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-07 01:41:49
|
Robert Love wrote: > Exactly. That is one reason. Another is that the #if 0 makes the tree > instantly incompatible with any arch other than SH. The SH tree should > be fully compatible with all arches, so that we can resync with each > other. Sorry, I don't share your view. No, I don't say you're wrong. I think that it's a sort of matter of taste or discipline (work style). Ideal stuation would be like that (fully compatible and fully synchronized), but there are some parts which is not, _always_. Sometimes, we have to maintain the differences, say, a year or so to get merged. It's unwise, well, quite impractical to ignore the existence of diversion. If it's really being synched, there is no sence to have SH repository, in the first place. And it has been _me_ (and I think still _is_) who work for the synchronization. And I ask you and others to leave it as #if 0, because it is good for me to do the synchronization work. Having SH repository, people only commit to the repository, not try to send the patch to main line. That's quite bad thing, because it may result more diversion and bad quality. I had spent much time for the work of synchronization, and my experience says "don't hide the issue if there is work remained for merge". If you really want (looks like) sane version, you can have your own version. Yes, it depends who does that. > Which brings me to the next point ... the trees are way out of sync. I agree I have things to be done. > When was the last time someone pushed an SH merge off to the official > kernel? It is me, because I am a maintainer. It was late 2.4.13. Since that time, because of the priority of GCC synchronization, I have been spent most of time to have GCC patches to gather, send to upstream, evaluate, generate local patches, etc. > I would be happy to put together a diff against the latest 2.4 and 2.5 > and send it off to Marcelo and Linus for merging into their tree. I > suspect it will take some work to make sure we keep the code correct > (ie, nothing like the #if 0 stuff). I would want the maintainer's > permission before I do this. Thanks for offering help, but no thank you for this work. It complicate things in a bad way, if I can't see how things are going. It is, say, "serialization". In many cases, this style works well, although sometimes it's the bottle neck. To avoid confusion of diversion, it is known to best to serialize merge of the work. > Second, with 2.5 starting, we need conversion to both CML2 and > kbuild-2.5. Yes. I think that I notified people some time last year, and Greg also mentioned last month. > Both are non-trivial changes. The SH port is the _only_ > piece of the kernel non-synced with CML2, supposedly at the maintainer's > request that he do it? No. I don't request. It's simple, I asked, but none does that. > Also, SH items in Configure.help are very lacking. CML2 will _not_ > allow an item to be selected if in non-expert mode if it has no > configure help! And kbuild-2.5 will require a rewrite of our > makefiles... Why don't you contribute this part? I think that there's no objection for 2.5 tree to do that job. If you don't have write access to the repository, please ask. -- |
|
From: M. R. B. <mr...@0x...> - 2001-12-07 02:22:47
|
* NIIBE Yutaka <gn...@m1...> on Fri, Dec 07, 2001: >=20 > Ideal stuation would be like that (fully compatible and fully > synchronized), but there are some parts which is not, _always_. > Sometimes, we have to maintain the differences, say, a year or so to > get merged. It's unwise, well, quite impractical to ignore the > existence of diversion. If it's really being synched, there is no > sence to have SH repository, in the first place. >=20 I can't buy that. Aren't one of the LinuxSH goals to make the SH arch backend available to everyone? What's the purpose of purposely maintaining a divergent tree, if doing so increases workload and has the potential to break things on our end? We should be much more active in fixing mainline as well as our port, see the post the last couple of days about removing segment.h from all source files (we needed that), etc. We shouldn't be isolationists, and encourage incompatibility. Especially when huge (and not so huge) companies have an invested interest in what we produce. IMHO, we have an SH repository so that each maintainer can work on her own areas of code in a semi-controlled fasion. Not so that we can just be "different". > And it has been _me_ (and I think still _is_) who work for the > synchronization. And I ask you and others to leave it as #if 0, > because it is good for me to do the synchronization work. >=20 Why? > Having SH repository, people only commit to the repository, not try to > send the patch to main line. That's quite bad thing, because it may > result more diversion and bad quality. I had spent much time for the > work of synchronization, and my experience says "don't hide the issue > if there is work remained for merge". >=20 No, that's what peer patch review is for. Everyone can see what patches are proposed and object to them before they go in. Nothing is being hidden. > If you really want (looks like) sane version, you can have your own > version. >=20 Are you proposing a fork? > Yes, it depends who does that. >=20 [...] >=20 > I agree I have things to be done. >=20 I can understand you having limited time to work on things, I've often delayed submissions for months because I didn't have the time to finish them. But that's the benefit of our style of development, anyone else who's willing can step up and help you out. Why refuse that help? >=20 > It is me, because I am a maintainer. It was late 2.4.13. Since that > time, because of the priority of GCC synchronization, I have been > spent most of time to have GCC patches to gather, send to upstream, > evaluate, generate local patches, etc.=20 >=20 I understand you've been busy with other tasks. But it's time that the SH tree catches up with the real world, and it's difficult to do that if we aren't regularly syncing back to Linus. How about this? Would you have a problem remaining the 2.4 maintainer, while someone else stepped up to become the 2.5 maintainer? Since we're talking about divergance anyway, the linux-2_4-branch and HEAD will soon become (think directory restructuring) as divergent as the gcc 3.0 branch and gcc HEAD. It's going to be a ton of more work than what exists for the 2.4 series today. Is there anyone else who'd even want the maintainers chair? >=20 > Thanks for offering help, but no thank you for this work. It > complicate things in a bad way, if I can't see how things are going. >=20 That's why we're all on this mailing list. We already submit to patch review ... how can you not see how things are going? IMO, we need to become much more organized for the 2.5 line of development. What I mean by organization is that we need to know when to send patches to mainline, notify each other what breaks and why and who's responsible for what areas of code. I'm currently the Dreamcast maintainer, but I have some non-DC code I'd like to submit which I would of course maintain if it got in. M. R. |
|
From: NIIBE Y. <gn...@m1...> - 2001-12-07 03:14:00
|
I don't propose the fork. I say, there's always things to merge. M. R. Brown wrote: > I can't buy that. Yes, I know. We have different view. > What's the purpose of purposely maintaining > a divergent tree, if doing so increases workload and has the potential to > break things on our end? We should be much more active in fixing mainline > as well as our port, see the post the last couple of days about removing > segment.h from all source files (we needed that), etc. We shouldn't be > isolationists, and encourage incompatibility. I don't say, we should encourage incompatibility or divergent tree. I said, we have to think about maintaining the divergence. Although we should do our best to minimize the divergence, there _is_ always divergence and it is quite important to maintain the divergence and merging. It takes time to do the merging, and since the band width (of human being) is limited resource, we should be careful to do the merging. > IMHO, we have an SH repository so that each maintainer can work on her > own areas of code in a semi-controlled fasion. Yes. You did good job towards this goal. Don't you think that part of mm/memory.c is maintained by me? > > And it has been _me_ (and I think still _is_) who work for the > > synchronization. And I ask you and others to leave it as #if 0, > > because it is good for me to do the synchronization work. > >=20 > > Why? Because I maintain this divergence of mm/memory.c. Obviously, it's ugly hack, but it's important for performance wise for SuperH or other relevant architecture. We need API change for cache handling routines for merge, but for a while it's good. It's definitely _not_ CONFIG_SUPERH thing. For me, it looks quite selfish and bad code for generic part of kernel to have CONFIG_SUPERH if it's not really needed. > No, that's what peer patch review is for. Everyone can see what patches > are proposed and object to them before they go in. Nothing is being > hidden. It's good tools. But unfortunately, it's not perfect. If some part is not going in, then, he has divergence in his working tree, isn't it? > I understand you've been busy with other tasks. But it's time that the SH > tree catches up with the real world, and it's difficult to do that if we > aren't regularly syncing back to Linus. I have been doing that. I don't think other person sending patches help things here. Say, do you believe RedHat users who find divergence between mainline and the kernel distributed by RedHat sending the difference to Linus? I don't think so. > How about this? Would you have a problem remaining the 2.4 maintainer, > while someone else stepped up to become the 2.5 maintainer? For me, 2.5 thing is better to follow. 2.4 is difficult. -- |
|
From: Tom R. <tr...@ke...> - 2001-12-07 04:12:22
|
On Thu, Dec 06, 2001 at 08:22:38PM -0600, M. R. Brown wrote: > > It is me, because I am a maintainer. It was late 2.4.13. Since that > > time, because of the priority of GCC synchronization, I have been > > spent most of time to have GCC patches to gather, send to upstream, > > evaluate, generate local patches, etc. > > > I understand you've been busy with other tasks. But it's time that the SH > tree catches up with the real world, and it's difficult to do that if we > aren't regularly syncing back to Linus. I hate to say it, but just because you send things to Linus, doesn't mean they get in. While it is important to try, it's just as important to have a good public tree that does work on an arch. If things actually got in for SH around 2.4.13 (I don't remember all of the changes in those pre-patches) SH is actually pretty well off in this regard. Maybe Marcelo will be better about it, but it'll still take time for everything to settle down.. > IMO, we need to become much more organized for the 2.5 line of development. > What I mean by organization is that we need to know when to send patches to > mainline, notify each other what breaks and why and who's responsible for > what areas of code. I'm currently the Dreamcast maintainer, but I have > some non-DC code I'd like to submit which I would of course maintain if it > got in. Just my two cents, what's worked well for PPC so far is having a tree that the active and knowledge able people can write to, keeping it close to kernel.org, and frequent patchbombing of Linus. We've also got a list for commit msgs, and with verbose comments (and followups) everyone usually knows what's going on. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ |
|
From: Robert L. <rm...@te...> - 2001-12-07 04:17:30
|
On Thu, 2001-12-06 at 23:11, Tom Rini wrote: > I hate to say it, but just because you send things to Linus, doesn't > mean they get in. While it is important to try, it's just as important > to have a good public tree that does work on an arch. If things > actually got in for SH around 2.4.13 (I don't remember all of the > changes in those pre-patches) SH is actually pretty well off in this > regard. Maybe Marcelo will be better about it, but it'll still take > time for everything to settle down.. Sadly true. However, I think we could convince him to merge something now in 2.5. As for 2.4, I already asked Marcelo if he would take a merge. He will. > Just my two cents, what's worked well for PPC so far is having a tree > that the active and knowledge able people can write to, keeping it close > to kernel.org, and frequent patchbombing of Linus. We've also got a > list for commit msgs, and with verbose comments (and followups) everyone > usually knows what's going on. PPC is very well up-to-date in the official tree, and I think that is a good thing. Good job. Robert Love |
|
From: Tom R. <tr...@ke...> - 2001-12-07 04:24:48
|
On Thu, Dec 06, 2001 at 11:17:23PM -0500, Robert Love wrote: > On Thu, 2001-12-06 at 23:11, Tom Rini wrote: > > > I hate to say it, but just because you send things to Linus, doesn't > > mean they get in. While it is important to try, it's just as important > > to have a good public tree that does work on an arch. If things > > actually got in for SH around 2.4.13 (I don't remember all of the > > changes in those pre-patches) SH is actually pretty well off in this > > regard. Maybe Marcelo will be better about it, but it'll still take > > time for everything to settle down.. > > Sadly true. However, I think we could convince him to merge something > now in 2.5. I guess see my other email. > As for 2.4, I already asked Marcelo if he would take a merge. He will. Yes, but that doesn't mean it will get in right away either. Marcelo has a patch for PPC right now that's waiting a quite enough -pre to drop in. :) > > Just my two cents, what's worked well for PPC so far is having a tree > > that the active and knowledge able people can write to, keeping it close > > to kernel.org, and frequent patchbombing of Linus. We've also got a > > list for commit msgs, and with verbose comments (and followups) everyone > > usually knows what's going on. > > PPC is very well up-to-date in the official tree, and I think that is a > good thing. Good job. PPC isn't nearly as up to date in kernel.org as you think. There's a very large patch right now, to be followed up by a few large (because lots of files move) patch and then even more small patches for new boards. Hopefully 2.4.20 or so will be really really good on PPC and a few other !x86 arches. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X