[Top] [All Lists]

Re: [patch] linux: DBE/IBE handling rewrite

To: Jun Sun <>
Subject: Re: [patch] linux: DBE/IBE handling rewrite
From: "Maciej W. Rozycki" <>
Date: Thu, 27 Jun 2002 22:00:47 +0200 (MET DST)
Cc: Ralf Baechle <>, Ladislav Michl <>,
In-reply-to: <>
Organization: Technical University of Gdansk
On Thu, 27 Jun 2002, Jun Sun wrote:

> Here are some of those on top of my mind.  And I am pretty sure I am missing 
> others:
> 1) /proc/cpuinfo and some bootinfo.h change  (I think these two come from one 
> change)

 Well, the addition of a FPU revision was my fault, but it was posted here
for discussion.  Now I am not completely satisfied with it, I admit, as
the implementation level is not reported -- only the revision.  I think
the implementation should be presented in a form of a textual name, like
it's done for the CPU, perhaps in a separate line.

 Others, I am not aware of.

> 2) split of cache and tlb files

 It was justified in my opinion.  Besides it was Ralf who did it, I
believe and that's his right of a MIPS maintainer, like Linus keeps the
right to change whatever he likes to within the kernel without asking
anyone.  That what makes someone a maintainer, after all.

> 3) some kind of flush_cache_LSB() routines.

 I can't recall, sorry.

> It is not big logically.  However, outside all the boards that are in oss 
> tree, I can safely say there are at least twenty MIPS porting efforts going 
> on 
> at various stages.  Next time those people sync up with oss, they will find 
> the missing symbol of bus_error_init().

 Well, they get what they deserve for not releasing early.  Still, I'm
trying my best not to break others' work.  You wouldn't get that luxury
with the official kernel -- once a subsystem gets reorganized, only basic
bits (usually i386 and the platform the author is working on) get adjusted
and the rest is left broken until someone interested fixes it.  There is a
benefit, though -- that's actually a good determinator of bits no one is
interested anymore.  If a configuration keeps impossible to be compiled
for a long time, it's a sign it may probably be scheduled for a removal

 OTOH, my private tree differs from the CVS by 36 patches now (a few less
as of today, as they got merged), which are awaiting an approval or are
unfinished or should really go to the official kernelor whatever and I can
live with that.  Occassionally I have to adjust them due to changes in the
CVS, but what's the deal? 

 Also when working on a change I usually don't switch kernels.  I let it
be finished, then try with a current snapshot, adjust as needed and only
then it's ready to be sent here and/or applied to the tree.  E.g. I'm
working on a serious update to the DECstation code and I use a snapshot
from May 30th.  Only when I consider it ready for merging I'll update its
working tree, even though I am already using a snapshot from Jun 25th for
other stuff.  Also I'll not wait for the update to be rock-solid -- I'll
merge it as soon as it's usable to some extent (unstable bits won't affect
existing code) and then I'll debug it myself as well as let others do that
if interested. 

 Plain and simple -- that's how the idea works.

> It wasn't my intention to dampen your MIPS contribution.  In fact, I start to 
> regret about my first email which now looks a little irresponsible.

 Not a problem -- we are all people after all and it's usually better to
express thoughts than to keep them inside.  This way you give others a
chance to clear the situation.

> If anything out of this thread can increase the awareness of open discussion 
> and awareness of the existence of many boards which are not part of oss tree 
> yet, I shall be happy.

 Well, I hope there will be benefits, as there usually are as a result of
good discussions.  For the writers of the external code I'd advise to try
merging as soon as they can, not only after code gets mature.  This way
others may try the code, comment on it and the code will have a chance to
be automatically adjusted whenever a more widespread change happens.  This
also minimizes a risk of a number of people working on the same problem in
parllel without knowing about one another.  There is hardly anything as
frustrating as duplicating somebody's work needlessly.


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

<Prev in Thread] Current Thread [Next in Thread>