linuxsh-dev

[linuxsh-dev] unmapped area for 16KB alignment

[NIIBE Y. <gn...@m1...>]

In current implementation, we get 4-KB alignment for mmap, 16KB when
shared.  It's better to have 16KB alignment all the time, because we
can share the cache entries.

Index: arch/sh/kernel/sys_sh.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/kernel/sys_sh.c,v
retrieving revision 1.6
diff -u -r1.6 sys_sh.c
--- arch/sh/kernel/sys_sh.c	2001/06/30 09:18:39	1.6
+++ arch/sh/kernel/sys_sh.c	2001/08/03 11:56:49
@@ -68,10 +68,7 @@
 	if (!addr)
 		addr = TASK_UNMAPPED_BASE;
 
-	if (flags & MAP_SHARED)
-		addr = COLOUR_ALIGN(addr);
-	else
-		addr = PAGE_ALIGN(addr);
+	addr = COLOUR_ALIGN(addr);
 
 	for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
 		/* At this point:  (!vma || addr < vma->vm_end). */
@@ -80,8 +77,7 @@
 		if (!vma || addr + len <= vma->vm_start)
 			return addr;
 		addr = vma->vm_end;
-		if (flags & MAP_SHARED)
-			addr = COLOUR_ALIGN(addr);
+		addr = COLOUR_ALIGN(addr);
 	}
 }
 #endif
-- 

[linuxsh-dev] Too many requests are merged

[NIIBE Y. <gn...@m1...>]

GD-ROM driver is ready for new block device interface, but too many
request can be merged by default.  As it's very slow, it's better not
merge the requests.

	* drivers/cdrom/gdrom.c (gdrom_init): Let block device layer
	not merge the requests.

Index: drivers/cdrom/gdrom.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/cdrom/gdrom.c,v
retrieving revision 1.3
diff -u -r1.3 gdrom.c
--- drivers/cdrom/gdrom.c	2001/08/03 11:22:06	1.3
+++ drivers/cdrom/gdrom.c	2001/08/03 11:56:49
@@ -437,6 +437,22 @@
 	name:		"gdrom",
 };
 
+/*
+ * This driver works with new merge interface, but if the merge occurs
+ * performance gets really worse.  Hence, we disable the merge of requests.
+ */
+static int dont_merge_requests_fn(request_queue_t *q, struct request *req,
+				  struct request *next, int max_segments)
+{
+	return 0;
+}
+
+static int dont_bh_merge_fn(request_queue_t *q, struct request *req,
+                            struct buffer_head *bh, int max_segments)
+{
+	return 0;
+}
+
 static int __init gdrom_init(void)
 {
 	request_queue_t * q; 
@@ -455,6 +471,9 @@
 
 	q = BLK_DEFAULT_QUEUE(MAJOR_NR);
 	blk_init_queue(q, DEVICE_REQUEST);
+	q->back_merge_fn = dont_bh_merge_fn;
+	q->front_merge_fn = dont_bh_merge_fn;
+	q->merge_requests_fn = dont_merge_requests_fn;
 	blksize_size[MAJOR_NR] = &gdrom_blocksize;
 	hardsect_size[MAJOR_NR] = &gdrom_hardsecsize;
 	read_ahead[MAJOR_NR] = 4;
-- 

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Greg B. <gb...@po...>]

Paul Mundt wrote:
> 
> On Fri, Aug 03, 2001 at 01:37:08PM +1000, Greg Banks wrote:
> >   But when the revision tree generalises, people's mental models start breaking
> > down.  How do you relate versions "1.5.1.6" and "1.7" ?   [...]
> >
> Versions aren't difficult to follow once the basic concepts are understood. One thing
> I'm kind of curious about though, is how you came up with the 1.5.1.6 number. This
> would indicate that a branch occured when the main trunk was at a revision of 1.5.
> Though branch numbers are done in even numbers, starting at 2, so you don't step on
> the magic branch numbers. Perhaps you meant 1.5.2.6 to indicate the 6th revision in
> the first branch off the main trunk from revision 1.5?

  I think you've just illustrated my point about CVS version numbers becoming
non-intuitive once you start using branches.

> I've also seen many experienced, clueful software engineers having issues with CVS
> branching. [...] CVS just requires you to do
> manually that which systems like BitKeeper do automagically.
> 
> [...] people not being able to pick up
> on this stuff fast enough. Branches and tags are still part of the CVS basics,
> and are only difficult if you make them so. [...]
> 
> Branching is only "ugly" because CVS doesn't do it for you. [...]
> 

  Right.

> Using two subdirectories or two branches isn't really any different. 

  ...except that...

> If you want
> to do work on an experimental branch, check it out, and do your work from there,
> making sure that the sticky tag is set to the experimental branch, while

  Yep, gotta remember that.

> making sure you're doing things under the right tag.

  Gotta remember that too.

> A drop-in tree can be done without CVS branches just fine, though CVS branches
> would be a lot cleaner in the long run.

  So basically, we spend a large learning curve and an indeterminate
number of mistakes to gain some cleanliness?  I'm not convinced 
this tradeoff is a good idea.

> If people don't like the idea of dealing
> with CVS branches, so be it. That still shouldn't have any bearing on the
> drop-in tree or CVS tag usage.

  Yes, separate issues.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Paul M. <pm...@mv...>]

On Fri, Aug 03, 2001 at 01:37:08PM +1000, Greg Banks wrote:
>   This is part of the problem: that part of CVS' functionality is difficu=
lt
> to use and confuses people.  Most people can conceptualise linear revisio=
n trees
> and deal with the practical issues of updating, adding files, and checking
> in changes.  It's easy to understand how revisions "1.3" and "1.7" relate;
> the numbering scheme appears (deceptively) to be what they're used to, and
> it maps easily to the time dimension.
>=20
>   But when the revision tree generalises, people's mental models start br=
eaking
> down.  How do you relate versions "1.5.1.6" and "1.7" ?   How do you expl=
ain
> sticky branch tags?  Then people have to start *thinking* about how they =
do
> things, and at this point they start making mistakes, usually resulting i=
n changes
> being checked into the wrong branch.  I've seen experienced, clueful soft=
ware
> specialists in a commercial environment make significant mistakes with CV=
S branches.
> What this does is generate confusion and more work for the people who hav=
e to
> clean it up; and no amount of explanation of "how it works" helps because=
 people
> just *won't* understand.
>=20
Versions aren't difficult to follow once the basic concepts are understood.=
 One thing
I'm kind of curious about though, is how you came up with the 1.5.1.6 numbe=
r. This
would indicate that a branch occured when the main trunk was at a revision =
of 1.5.
Though branch numbers are done in even numbers, starting at 2, so you don't=
 step on
the magic branch numbers. Perhaps you meant 1.5.2.6 to indicate the 6th rev=
ision in
the first branch off the main trunk from revision 1.5?

Relating 1.5.2.6 and 1.7 isn't quite that difficult.. one resides off a bra=
nch with
its own revision history, the other resides in the main trunk. Though why y=
ou would
be feeding revisions through the main trunk when things should just go thro=
ugh the
current stable branch is beyond me.

Sticky branch tags aren't anything revolutionary or complex either. I'm sur=
e if
people spent a few minutes alone with the 'cvs status' command, half this s=
tuff
would indeed not be an issue.

I've also seen many experienced, clueful software engineers having issues w=
ith CVS
branching. Most of these problems originated from not reading documentation=
, or
not knowing where to find documentation (which is another issue entirely). =
The
branching concept is nothing new or complicated, CVS just requires you to do
manually that which systems like BitKeeper do automagically.

I think the majority of your concerns stem from people not being able to pi=
ck up
on this stuff fast enough. Branches and tags are still part of the CVS basi=
cs,
and are only difficult if you make them so. A relatively simple concept is =
just
that, needless confusion isn't CVS's fault. There is also numerous document=
ation
available on how to do clean and proper branching.. such as the CVS Book, w=
hich
includes walk throughs and all that kind of fun stuff. A quick tutorial on =
the
matter should be suffecient IMO.

>   Remember, 18 months ago many of the LinuxSH developers had never used C=
VS and
> basic CVS features like automatic merge were new and exciting.  Part of t=
he process
> of selling CVS involved demonstrating how easy and simple it is, which me=
ant of
> course hiding the ugly bits like branches.
>=20
Branching is only "ugly" because CVS doesn't do it for you. CVS is a tool, =
not a
hold-your-hand-through-the-basics-of-source-control crutch. CVS does indeed=
 have
its problems, but things like branching are fairly well documented, and sho=
uldn't
be that hard to get ones head around after spending a bit of time playing w=
ith it.

>   For exactly two pre-determined branches which will diverge, the full po=
wer of CVS
> branches is not necessary.  Using two subdirectories of $CVSROOT is perfe=
ctly adequate,
> and is much easier to explain to people whose primary job is making hardw=
are work, not
> CVS finagling.
>=20
Using two subdirectories or two branches isn't really any different. If you=
 want
to do work on an experimental branch, check it out, and do your work from t=
here,
making sure that the sticky tag is set to the experimental branch, while
making sure you're doing things under the right tag.

I agree people should spend more time writing code than twiddling with CVS,=
 but
spending a bit of time on CVS now to save more time later seems to have eno=
ugh
benefits IMO.

>   I'm not trying to defend the current setup (even though I was one of
> the people who argued for it and set it up).  The most I will say for the
> current setup is that it was an improvement at the time.
>=20
>   I like the idea of a drop-in tree, I think it's a huge improvement in m=
any
> ways, I even toyed with the idea internally at PocketPenguins.  My role h=
ere
> is devil's advocate, trying to ensure that M.R.'s proposals cover all the=
 issues
> and can stand up to counter-argument.
>=20
A drop-in tree can be done without CVS branches just fine, though CVS branc=
hes
would be a lot cleaner in the long run. If people don't like the idea of de=
aling
with CVS branches, so be it. That still shouldn't have any bearing on the
drop-in tree or CVS tag usage.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Greg B. <gb...@po...>]

Paul Mundt wrote:
> 
> On Fri, Aug 03, 2001 at 11:14:40AM +1000, Greg Banks wrote:
> > > [...] As the drop-in trees are much smaller than the full kernel,
> > wouldn't it be simpler to have two CVS modules, one each for stable and
> > experimental trees?
> >
> Er, this is exactly what the branches are for. [...]

  I'm not arguing from ignorance here, but from bitter experience.  See below.

> >   You may be able to tell, I've had *bad* experiences with CVS branches before.
> >
> The majority of bad experiences come from people improperly setting up/using
> CVS branches. It's amazing the number of repositories out there that aren't
> being run properly at all, simply because people don't know how to use CVS.

  This is part of the problem: that part of CVS' functionality is difficult
to use and confuses people.  Most people can conceptualise linear revision trees
and deal with the practical issues of updating, adding files, and checking
in changes.  It's easy to understand how revisions "1.3" and "1.7" relate;
the numbering scheme appears (deceptively) to be what they're used to, and
it maps easily to the time dimension.

  But when the revision tree generalises, people's mental models start breaking
down.  How do you relate versions "1.5.1.6" and "1.7" ?   How do you explain
sticky branch tags?  Then people have to start *thinking* about how they do
things, and at this point they start making mistakes, usually resulting in changes
being checked into the wrong branch.  I've seen experienced, clueful software
specialists in a commercial environment make significant mistakes with CVS branches.
What this does is generate confusion and more work for the people who have to
clean it up; and no amount of explanation of "how it works" helps because people
just *won't* understand.

  Remember, 18 months ago many of the LinuxSH developers had never used CVS and
basic CVS features like automatic merge were new and exciting.  Part of the process
of selling CVS involved demonstrating how easy and simple it is, which meant of
course hiding the ugly bits like branches.

  So let's *not* start confusing the people who generate the actual useful working code.

  For exactly two pre-determined branches which will diverge, the full power of CVS
branches is not necessary.  Using two subdirectories of $CVSROOT is perfectly adequate,
and is much easier to explain to people whose primary job is making hardware work, not
CVS finagling.

> > 1.  procedures are feasible
> > 2.  everyone understands how they work
> > 3.  Niibe-san agrees with it
> >
> #1 should be taken care of when #2 is done properly. #2 could easily be
> acheived with a test tree and some documentation outlining how to use it.

  Yes.

> #3 would follow #2 and #1 being successful, or so I would think. Though that
> all depends how much Niibe-san likes drop-in trees and CVS branching/tagging.

  Yes.

> > > [...drop-in tree...]
> >   I agree, that's why the question is not "can it be better?" but "will it work?".
> >
> It's worked for everyone else, so I don't see it as being a hinderance here.

  Yes.

> I guess we can't say one way or another until it gets tried.

  Yes.
  
> Breakage is going to happen regardless, it's unavoidable. This isn't CVS's
> problem, this is something that's going to happen in any experimental tree.
> (Note: that's why it's experimental, not stable). [...] I don't see how CVS
> makes this a problem.
> 
> Perhaps I'm misunderstanding what you're getting at,

  Just trying to clear up my own sloppy use of terminology.  I was using
"manual merge" to mean the entire process of CVS automatic textual merge
plus manually fixing the breakages.  In your last post you seemed to be
interpreting "manual merge" in the narrower sense of doing the textual
merge manually.  This was a reasonable interpretation, but not what I
meant (oops).

> but I don't see
> anything you've listed above as being a problem with CVS or the drop-in tree
> design. 

  I agree.  These problems are inherent and no version control arrangement
will make them go away, and I don't intend to imply otherwise.  They're not
a problem of CVS or of either a full or drop-in tree.

  This was the point I was trying to make to M.R., who seemed to believe
that a drop-in tree would somehow magically make these problems disappear.
I quote:

Greg Banks>   Also, this same recurrent breakage means that the drop-in would
Greg Banks> practically only work with a single mainline kernel version, maybe two or
Greg Banks> three if we're lucky.  How do you propose to manage that?

M.R. Brown> As long as the drop-in tree can be easily sync'd with mainline patchlevels,
M.R. Brown> and we can figure out and/or fix why we get continuous breakage, this won't
M.R. Brown> be an issue.

  Afterwards, he mentioned the AGAINST-x.y.z file, which addresses the issue.

> These look like nothing but general issues that arise from any kind
> of kernel work across multiple revisions, and isn't something that can be
> avoided.

  Yes.

> CVS makes a lot of this a lot cleaner, as it does a lot of the
> work for you, you're just required to do the cleanup on stuff that rejects
> or stuff that breaks afterwards.

  Yes.

> Plus, with proper tagged branches, it's
> a lot simpler to track the history of things and follow API changes more
> closely.

  I think we agree on the value of (normal) tags, but disagree on the value
of branches.

> Try doing that in the current tree.

  I'm not trying to defend the current setup (even though I was one of
the people who argued for it and set it up).  The most I will say for the
current setup is that it was an improvement at the time.

  I like the idea of a drop-in tree, I think it's a huge improvement in many
ways, I even toyed with the idea internally at PocketPenguins.  My role here
is devil's advocate, trying to ensure that M.R.'s proposals cover all the issues
and can stand up to counter-argument.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Paul M. <pm...@mv...>]

On Fri, Aug 03, 2001 at 11:14:40AM +1000, Greg Banks wrote:
> > the best way to do it would be to have one person handling the stable, =
and
> > someone else handling the experimental.
>=20
>   Sounds like a good idea.
>=20
>   But it seems to me that would make using CVS branches even messier than=
 usual.
> For example, when files get renamed or moved to different directories in =
the
> experimental branch.  As the drop-in trees are much smaller than the full=
 kernel,
> wouldn't it be simpler to have two CVS modules, one each for stable and
> experimental trees?
>=20
Er, this is exactly what the branches are for. Stable development (2.4.x)
would be done on a stable branch, and experimental (2.5.x) would be done on=
 an
experimental branch. Under each branch, new versions would be done under ta=
gs.
ie, 2.4.8 comes out .. required updates are done, and result is tagged as a
2.4.8 release and pushed back into the stable branch. At this point, people
could still grab a 2.4.7 tagged repository. There's no point in that time in
maintaining old things, as the current stable and current experimental are =
the
only ones that'd be under development. Tagged previous revisions would just=
 be
there for archival, and provide a simple means for people to grab the tree =
for
their kernel version.

>   You may be able to tell, I've had *bad* experiences with CVS branches b=
efore.
>=20
The majority of bad experiences come from people improperly setting up/using
CVS branches. It's amazing the number of repositories out there that aren't
being run properly at all, simply because people don't know how to use CVS.

> > Either way, dealing with a drop-in tree cuts down maintenance time dras=
tically.
>=20
>   I believe it's possible, but I'd like to see it demonstrated.  What we
> have now is clunky and painful for everyone, but we know how to make it
> work.  I'd like to see a plan for improvement which also works.  Practica=
lly,
> this means:
>=20
> 1.  procedures are feasible
> 2.  everyone understands how they work
> 3.  Niibe-san agrees with it
>=20
#1 should be taken care of when #2 is done properly. #2 could easily be
acheived with a test tree and some documentation outlining how to use it.

#3 would follow #2 and #1 being successful, or so I would think. Though that
all depends how much Niibe-san likes drop-in trees and CVS branching/taggin=
g.

>   I don't like CVS branches, especially the futzing that goes on around
> adding, renaming, or moving files in one or both branches.  CVS branches
> are adequate for small experimental excursions which get merged back
> into the mainline after a few revisions.  However for large diverging
> changes like the experimental kernel, they're Trouble.  I'd be a lot
> happier with two modules.
>=20
This moving around and other such issues are only a concern when you're dea=
ling
with multiple branches of the same thing. In this case, we'd only be having=
 a
stable and an experimental branch, and then having kernel versions tagged.
Stable and experimental would have to be kept seperate anyways, so you're n=
ot
really doing any _extra_ work by doing a branched/tagged approach.

As far as CVS is concerned, they are two modules. The user just has to know
which one they want to check out.. the head should always point to the curr=
ent
stable.

> > You would have to think long and hard about any disadvantages to a drop=
-in
> > tree that you wouldn't have to an entire tree. With the drop-in tree de=
sign,
> > you only ever touch that which is necessary to be modified by the tree.=
 There
> > is no reason to track other changes in the tree, as they don't concern =
the
> > tree, and are just a wasted effort.
>=20
>   I agree, that's why the question is not "can it be better?" but "will i=
t work?".
>=20
It's worked for everyone else, so I don't see it as being a hinderance here=
. I
guess we can't say one way or another until it gets tried.

>   The problem is that after CVS has done the textual merge, more subtle
> problems appear, which need to be found and fixed manually.  To construct
> a synthetic example, imagine that the mainline changed the name of a
> field in struct console.  This then causes one of our files, drivers/char=
/sh-sci.c
> to fail to compile (it uses named field initialisation of a static
> struct console).  So we need to tweak our file to follow the global chang=
e.
>=20
>   Note of course, this is an *easy* one.  The breakage is deliberate, occ=
urs
> at compile time and the fix is obvious.  Now when subtle behaviours of VM
> functions change...
>=20
>   This is the gnarly manual step I've been referring to.
>=20
>   While deliberate breakage happens relatively infrequently in the stable
> kernel, accidental breakage happens often enough to make each merge an
> adventure.  Both deliberate and accidental breakage will happen a *lot* in
> the early days of the new experimental kernel, as all the patches people
> have been holding off sending to Linus go flooding in.
>=20
Breakage is going to happen regardless, it's unavoidable. This isn't CVS's
problem, this is something that's going to happen in any experimental tree.
(Note: that's why it's experimental, not stable). An API or some such thing
being totally restructured, or entire subsystems being swapped out for new
ones, are all common place for an experimental tree. I don't see how CVS
makes this a problem.

Perhaps I'm misunderstanding what you're getting at, but I don't see
anything you've listed above as being a problem with CVS or the drop-in tree
design. These look like nothing but general issues that arise from any kind
of kernel work across multiple revisions, and isn't something that can be
avoided. CVS makes a lot of this a lot cleaner, as it does a lot of the
work for you, you're just required to do the cleanup on stuff that rejects
or stuff that breaks afterwards. Plus, with proper tagged branches, it's
a lot simpler to track the history of things and follow API changes more
closely. Try doing that in the current tree.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

[linuxsh-dev] Files for 7751 Solution Engine

[NIIBE Y. <gn...@m1...>]

Jeremy Siegel wrote:
 > So -- we haven't really improved anything,
 > but I've attached a patch to separate the 7751
 > Solution Engine stuff from the regular Solution
 > Engine (7709, 7750, etc.)... can I get the ok to
 > check it in?

Thanks, please check it in.
-- 

[linuxsh-dev] Files for 7751 Solution Engine

[Jeremy S. <js...@mv...>]

A couple months ago we added support for the 7751
Solution Engine (well, absolute minimal stuff) and
Niibe-san requested that it be made a new machine
type.  So -- we haven't really improved anything,
but I've attached a patch to separate the 7751
Solution Engine stuff from the regular Solution
Engine (7709, 7750, etc.)... can I get the ok to
check it in?

(Yeah, I do read this list, and I realize this is likely
a rotten time to be asking to include a patch which
adds more mach_xxxx.c type stuff in arch/sh/kernel
and the like... but unless and until the tree structure
does change, that's where it goes.  And if it does
change, I'll happily participate in the restructuring
as much as I'm able!)

Thanks,
  --Jeremy Siegel

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Mitch D. <mj...@cy...>]

Greg Banks wrote:
> 
>   Yes.  However, let me share some bitter experience: it can take months
> and lots of effort to get patches accepted in the mainline.  If it hadn't
> been for Mitch's amazing persistence my HD64465 PCMCIA code would never have
> gotten in.

<laughing>

That was because I was naiive enough to think
it could be done! :-)

Mitch: "It can't be that hard, you're making a mountain
        out of a molehill".
Greg:  "Well I mailed Linus twice".
Mitch: "Let me have a go"

I eventually got it in by mailing Alan Cox a few times,
and David Hinds a few times, and Alan a few more times.
But it was really worth it.

Regards,

Mitch.
-- 
The GPL is a lot like an alligator snout.  You can hold it shut
with one hand, but if you stick your head in it bites like hell.
mailto:mj...@cy...                               - Nathan Myers
mailto:mj...@al...

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Greg B. <gb...@po...>]

Paul Mundt wrote:
> 
> On Wed, Aug 01, 2001 at 09:32:29PM +1000, Greg Banks wrote:
> >   So, when 2.5 is released, we start up a second drop-in tree
> > for 2.5.x, while keeping the first 2.4.x drop-in tree?
> >
> >   What happens if 2.5.x is released before this gets organised (a real
> > possibility)?  Do we then generate two seperate drop-in trees?
> >
> This is just a matter of maintaining two drop-in trees. They could just
> be tagged as development and stable branches and be dealt with accordingly
> under CVS. The PPC tree uses the same sort of convention, except they don't
> do drop-in trees, and they use BitKeeper for source control.
> 
> This isn't really that big of a deal..

  I'm not raising objections, just trying to figure out exactly what M.R.
is proposing here so that I can have an informed opinion.

> the best way to do it would be to have
> one person handling the stable, and someone else handling the experimental.

  Sounds like a good idea.

  But it seems to me that would make using CVS branches even messier than usual.
For example, when files get renamed or moved to different directories in the
experimental branch.  As the drop-in trees are much smaller than the full kernel,
wouldn't it be simpler to have two CVS modules, one each for stable and
experimental trees?

  You may be able to tell, I've had *bad* experiences with CVS branches before.

> Either way, dealing with a drop-in tree cuts down maintenance time drastically.

  I believe it's possible, but I'd like to see it demonstrated.  What we
have now is clunky and painful for everyone, but we know how to make it
work.  I'd like to see a plan for improvement which also works.  Practically,
this means:

1.  procedures are feasible
2.  everyone understands how they work
3.  Niibe-san agrees with it

> In addition to this, it might be useful to start using proper CVS branches
> and tags in CVS to make maintenance and such easier. ie, everything can be
> under the same module in CVS, and newer revisions are simply inserted under
> their own tag on their respective branch.. with the head always pointing to
> the current stable.

  Fmeh.

  I like CVS tags, and we used to use them up until 2.4.0-test3-pre5.
I suspect Niibe-san stopped using them because with a full kernel
they take so long and don't win you anything you can't do with
a "cvs co -D".  With a drop-in tree, the trade-off changes.

  I don't like CVS branches, especially the futzing that goes on around
adding, renaming, or moving files in one or both branches.  CVS branches
are adequate for small experimental excursions which get merged back
into the mainline after a few revisions.  However for large diverging
changes like the experimental kernel, they're Trouble.  I'd be a lot
happier with two modules.

> 
> > > Now the argument may be "why abandon the current full kernel tree then?"
> >
> >   I think the argument is "how can we make a drop-in tree workable for us?".
> >
> You would have to think long and hard about any disadvantages to a drop-in
> tree that you wouldn't have to an entire tree. With the drop-in tree design,
> you only ever touch that which is necessary to be modified by the tree. There
> is no reason to track other changes in the tree, as they don't concern the
> tree, and are just a wasted effort.

  I agree, that's why the question is not "can it be better?" but "will it work?".

> > > As long as the drop-in tree can be easily sync'd with mainline patchlevels,
> >
> >   I don't see how.  It will require someone -- almost certainly Niibe-san --
> > to do frequent time-consuming merges.  Just like he does now.  The difference
> > is that the final check-in will be much smaller.
> >
> Manual merging should be nothing short of a last resort. CVS deals with
> branch merging just fine for the most part, and the few rejects it leaves
> can be cleaned up by hand afterwards. It's totally counter productive to do
> merges by hand of everything when the source control tool can deal with the
> majority of it for you.

  Sorry, I wasn't being clear here.  I'm not talking about manually doing
the textual merge of two streams of changes to the same file, which CVS
does on "cvs up".  This is *not* the problem.  We do have several files
where this happens, such as our changes to kernel/ or mm/, and sometimes
Linus makes changes in SH-specific code.  CVS handles these just fine.

  The problem is that after CVS has done the textual merge, more subtle
problems appear, which need to be found and fixed manually.  To construct
a synthetic example, imagine that the mainline changed the name of a
field in struct console.  This then causes one of our files, drivers/char/sh-sci.c
to fail to compile (it uses named field initialisation of a static
struct console).  So we need to tweak our file to follow the global change.

  Note of course, this is an *easy* one.  The breakage is deliberate, occurs
at compile time and the fix is obvious.  Now when subtle behaviours of VM
functions change...

  This is the gnarly manual step I've been referring to.

  While deliberate breakage happens relatively infrequently in the stable
kernel, accidental breakage happens often enough to make each merge an
adventure.  Both deliberate and accidental breakage will happen a *lot* in
the early days of the new experimental kernel, as all the patches people
have been holding off sending to Linus go flooding in.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

[linuxsh-dev] Protect P2 jump

[NIIBE Y. <gn...@m1...>]

I still see occasional (quite rare, but occurs) problem under heavy
use, which I believe cache alias issue or something like that.

I've protected the code which runs at P2.  Here's the patch.  With
this, so far, so good.

If possible, could Hitachi people confirm this?  Is it true we should
protect the interrupt when we run cache handling at P2?  If it is true,
I'd rather prefer it mentioned in the hardware manual.

2001-08-03  NIIBE Yutaka  <gn...@m1...>

	* arch/sh/mm/cache-sh4.c (flush_cache_sigtramp): Protect from
	interrupt.
	(__flush_cache_page, __flush_icache_page): Likewise.
	(check_cache_page): Likewise.

--- kernel/arch/sh/mm/cache-sh4.c	Fri Aug  3 09:04:52 2001
+++ kernel/arch/sh/mm/cache-sh4.c	Fri Aug  3 08:42:03 2001
@@ -192,6 +192,7 @@ void flush_icache_range(unsigned long st
 void flush_cache_sigtramp(unsigned long addr)
 {
 	unsigned long v, index;
+	unsigned long flags; 
 
 	v = addr & ~(L1_CACHE_BYTES-1);
 	asm volatile("ocbwb	%0"
@@ -199,9 +200,11 @@ void flush_cache_sigtramp(unsigned long 
 		     : "m" (__m(v)));
 
 	index = CACHE_IC_ADDRESS_ARRAY| (v&CACHE_IC_ENTRY_MASK);
+	save_and_cli(flags);
 	jump_to_P2();
 	ctrl_outl(0, index);	/* Clear out Valid-bit */
 	back_to_P1();
+	restore_flags(flags);
 }
 
 /*
@@ -211,9 +214,11 @@ void flush_cache_sigtramp(unsigned long 
 void __flush_cache_page(unsigned long phys, int exec)
 {
 	unsigned long addr, data;
+	unsigned long flags;
 
 	phys|=CACHE_VALID;
 
+	save_and_cli(flags);
 	jump_to_P2();
 	/* Loop all the D-cache */
 	for (addr = CACHE_OC_ADDRESS_ARRAY;
@@ -236,14 +241,17 @@ void __flush_cache_page(unsigned long ph
 				ctrl_outl(0, addr);
 		}
 	back_to_P1();
+	save_and_cli(flags);
 }
 
 void __flush_icache_page(unsigned long u0, unsigned long phys)
 {
 	unsigned long addr, data;
+	unsigned long flags;
 
 	phys|=CACHE_VALID;
 
+	save_and_cli(flags);
 	if (u0) {
 		jump_to_P2();
 		/* Loop half of the I-cache */
@@ -269,6 +277,7 @@ void __flush_icache_page(unsigned long u
 		}
 		back_to_P1();
 	}
+	restore_flags(flags);
 }
 
 /*
@@ -377,12 +386,14 @@ void check_cache_page(struct page *pg)
 	unsigned long kaddr;
 	unsigned long cache_line_index;
 	int bingo = 0;
+	unsigned long flags;
 
 	/* Physical address of this page */
 	phys = PHYSADDR(page_address(pg));
 	kaddr = phys + PAGE_OFFSET;
 	cache_line_index = (kaddr&CACHE_OC_ENTRY_MASK)>>CACHE_OC_ENTRY_SHIFT;
 
+	save_and_cli(flags);
 	jump_to_P2();
 	/* Loop all the D-cache */
 	for (i=0; i<CACHE_OC_NUM_ENTRIES; i++) {
@@ -411,14 +422,17 @@ void check_cache_page(struct page *pg)
 		}
 	}
 	back_to_P1();
+	restore_flags(flags);
 
 	if (bingo) {
 		extern void dump_stack(void);
 
 		if (bingo&1)
 			printk("BINGO!\n");
+#if 0
 		if (bingo&2)
 			printk("Bingo!\n");
+#endif
 		dump_stack();
 		printk("--------------------\n");
 	}
-- 

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Greg B. <gb...@po...>]

"M. R. Brown" wrote:
> 
> * Greg Banks <gb...@po...> on Wed, Aug 01, 2001:
> 
> >
> >   So, when 2.5 is released, we start up a second drop-in tree
> > for 2.5.x, while keeping the first 2.4.x drop-in tree?
> 
> Yes[...]
> 
> >
> >   What happens if 2.5.x is released before this gets organised (a real
> > possibility)?  Do we then generate two seperate drop-in trees?
> >
> [...] yeah,[...]

  I assume both of these two drop-in trees live in sourceforge CVS.  What
happens to the old full tree in CVS?

  Also, do you intend to do both directory reorganisation and creation of
a drop-in tree in the same manuoevre, or as two distinct stages?

> >   I don't see how.  It will require someone -- almost certainly Niibe-san --
> > to do frequent time-consuming merges.  Just like he does now.  The difference
> > is that the final check-in will be much smaller.
> 
> Yes, and working with the smaller subset of files helps to ease that process.

  I'm yet to be convinced that the merge process is any easier, apart from
the long wait for CVS to upload hundreds of useless changes to files we don't
care about.  The gnarly manual bits in the middle are no different.  In other
words, the hard work is the same and the part where you have a cup of coffee
is shorter.

  Clearly, the download process for everyone else *is* heaps easier, plus we
use less CVS space, both of which are good.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] Cache coherency issue

[SUGIOKA T. <su...@it...>]

At 20:06 01/08/02 , SUGIOKA Toshinobu <su...@it...> wrote:
>It seems to me that if we use __flush_purge_region()/ocbp here instead of
>__flush_invalidate_region()/ocbi then the change of mm/memory.c is not needed.

Sorry, I didn't read NIIBE-san's next mail.
Please ignore this comment.


-----
SUGIOKA Toshinobu

[linuxsh-dev] Cache coherency issue

[NIIBE Y. <gn...@m1...>]

I think I'll commit following change instead.  This doesn't change
cache handling behavior.  Only bug fix for maple.c (to invalidate), 
and interface clean up.

001-08-02  NIIBE Yutaka  <gn...@m1...>

	* drivers/maple/maple.c (maple_send): Bug fix.  Call
	dma_cache_wback_inv. (was: __flush_wback_region).

	* include/asm-sh/io.h (dma_cache_wback_inv, dma_cache_inv,
	dma_cache_wback): Defined with new __flush_XXX_region functions.
	(was: bogus cache_XXX_area functions, not implemented).

	* drivers/cdrom/gdrom.c (gdrom_intr): Follow the change of
	the last argument of __flush_wback_region.
	* include/asm-sh/ide.h (ide_insw): Likewise.

	* arch/sh/mm/cache-sh4.c (__flush_purge_region): New function.
	(__flush_icache_page): New function. 
	(__flush_wback_region, __flush_invalidate_region): Last argument
	is SIZE (was: END).

	* include/asm-sh/pgtable.h (__flush_purge_region,
	__flush_icache_page): Added.

Index: arch/sh/mm/cache-sh4.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache-sh4.c,v
retrieving revision 1.7
diff -u -r1.7 cache-sh4.c
--- arch/sh/mm/cache-sh4.c	2001/07/28 15:12:46	1.7
+++ arch/sh/mm/cache-sh4.c	2001/08/02 12:21:45
@@ -125,12 +125,14 @@
  *
  * START, END: Virtual Address (U0, P1, or P3)
  */
-void __flush_wback_region(void *start, void *end)
+void __flush_wback_region(void *start, int size)
 {
 	unsigned long v;
+	unsigned long begin, end;
 
-	for (v = (unsigned long)start& ~(L1_CACHE_BYTES-1);
-	     v < (unsigned long)end; v+=L1_CACHE_BYTES) {
+	begin = (unsigned long)start& ~(L1_CACHE_BYTES-1);
+	end = begin + size;
+	for (v = begin; v < end; v+=L1_CACHE_BYTES) {
 		asm volatile("ocbwb	%0"
 			     : /* no output */
 			     : "m" (__m(v)));
@@ -138,14 +140,36 @@
 }
 
 /*
+ * Write back the dirty D-caches and invalidate them.
+ *
+ * START, END: Virtual Address (U0, P1, or P3)
+ */
+void __flush_purge_region(void *start, int size)
+{
+	unsigned long v;
+	unsigned long begin, end;
+
+	begin = (unsigned long)start& ~(L1_CACHE_BYTES-1);
+	end = begin + size;
+	for (v = begin; v < end; v+=L1_CACHE_BYTES) {
+		asm volatile("ocbp	%0"
+			     : /* no output */
+			     : "m" (__m(v)));
+	}
+}
+
+
+/*
  * No write back please
  */
-void __flush_invalidate_region(unsigned long start, unsigned long end)
+void __flush_invalidate_region(void *start, int size)
 {
 	unsigned long v;
+	unsigned long begin, end;
 
-	start &= ~(L1_CACHE_BYTES-1);
-	for (v = start; v < end; v+=L1_CACHE_BYTES) {
+	begin = (unsigned long)start& ~(L1_CACHE_BYTES-1);
+	end = begin + size;
+	for (v = begin; v < end; v+=L1_CACHE_BYTES) {
 		asm volatile("ocbi	%0"
 			     : /* no output */
 			     : "m" (__m(v)));
@@ -214,6 +238,39 @@
 	back_to_P1();
 }
 
+void __flush_icache_page(unsigned long u0, unsigned long phys)
+{
+	unsigned long addr, data;
+
+	phys|=CACHE_VALID;
+
+	if (u0) {
+		jump_to_P2();
+		/* Loop half of the I-cache */
+		for (addr = CACHE_IC_ADDRESS_ARRAY|(u0&0x1000);
+		     addr < ((CACHE_IC_ADDRESS_ARRAY|(u0&0x1000))
+			     +(CACHE_IC_NUM_ENTRIES/2<<CACHE_IC_ENTRY_SHIFT));
+		     addr += (1<<CACHE_IC_ENTRY_SHIFT)) {
+			data = ctrl_inl(addr)&(0x1ffff000|CACHE_VALID);
+			if (data == phys)
+				ctrl_outl(0, addr);
+		}
+		back_to_P1();
+	} else {
+		jump_to_P2();
+		/* Loop all the I-cache */
+		for (addr = CACHE_IC_ADDRESS_ARRAY;
+		     addr < (CACHE_IC_ADDRESS_ARRAY
+			     +(CACHE_IC_NUM_ENTRIES << CACHE_IC_ENTRY_SHIFT));
+		     addr += (1<<CACHE_IC_ENTRY_SHIFT)) {
+			data = ctrl_inl(addr)&(0x1ffff000|CACHE_VALID);
+			if (data == phys)
+				ctrl_outl(0, addr);
+		}
+		back_to_P1();
+	}
+}
+
 /*
  * Write back & invalidate the I/D-cache of the page.
  * (To avoid "alias" issues)
@@ -222,17 +279,13 @@
 {
 	if (!pg->mapping
 	    || pg->mapping->i_mmap || pg->mapping->i_mmap_shared) {
-		int exec;
 		unsigned long phys;
 
-		if (!pg->mapping)
-			exec = 0;
-		else
-			exec = 1;
-
-		/* Physical address of this page */
 		phys = PHYSADDR(page_address(pg));
-		__flush_cache_page(phys, exec);
+		if (pg->mapping)
+			__flush_cache_page(phys, 1);
+		else
+			__flush_cache_page(phys, 0);
 	} else
 		set_bit(PG_dcache_dirty, &pg->flags);
 }
@@ -310,7 +363,7 @@
 	entry = *pte;
 	if (pte_none(entry) || !pte_present(entry))
 		return;
-	phys = PHYSADDR(pte_val(entry))&PAGE_MASK;
+	phys = PHYSADDR(pte_val(entry)&PAGE_MASK);
 	__flush_cache_page(phys, (vma->vm_flags & VM_EXEC));
 }
 
@@ -383,7 +436,7 @@
 {
 	if (((address ^ (unsigned long)to) & CACHE_ALIAS) == 0) {
 		clear_page(to);
-		__flush_wback_region(to, to+PAGE_SIZE);
+		__flush_wback_region(to, PAGE_SIZE);
 	} else {
 		pgprot_t pgprot = __pgprot(_PAGE_PRESENT | 
 					   _PAGE_RW | _PAGE_CACHABLE |
@@ -420,7 +473,7 @@
 {
 	if (((address ^ (unsigned long)to) & CACHE_ALIAS) == 0) {
 		copy_page(to, from);
-		__flush_wback_region(to, to+PAGE_SIZE);
+		__flush_wback_region(to, PAGE_SIZE);
 	} else {
 		pgprot_t pgprot = __pgprot(_PAGE_PRESENT | 
 					   _PAGE_RW | _PAGE_CACHABLE |
Index: arch/sh/mm/init.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/init.c,v
retrieving revision 1.17
diff -u -r1.17 init.c
--- arch/sh/mm/init.c	2001/07/24 05:24:33	1.17
+++ arch/sh/mm/init.c	2001/08/02 12:21:46
@@ -144,7 +144,7 @@
 
 	/* clear the zero-page */
 	memset(empty_zero_page, 0, PAGE_SIZE);
-	__flush_wback_region(empty_zero_page, empty_zero_page+PAGE_SIZE);
+	__flush_wback_region(empty_zero_page, PAGE_SIZE);
 
 	/* this will put all low memory onto the freelists */
 	totalram_pages += free_all_bootmem_node(NODE_DATA(0));
Index: drivers/cdrom/gdrom.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/cdrom/gdrom.c,v
retrieving revision 1.2
diff -u -r1.2 gdrom.c
--- drivers/cdrom/gdrom.c	2001/07/31 07:03:58	1.2
+++ drivers/cdrom/gdrom.c	2001/08/02 12:21:46
@@ -144,7 +144,7 @@
 		}
 
 		insw(GDROM_DATA, ctrl->buf, count/2); 
-		__flush_wback_region(ctrl->buf, ctrl->buf + count);
+		__flush_wback_region(ctrl->buf, count);
 		ctrl->buf += count;
 		ctrl->size -= count;
 	}
Index: drivers/maple/maple.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/maple/maple.c,v
retrieving revision 1.5
diff -u -r1.5 maple.c
--- drivers/maple/maple.c	2001/07/30 13:01:42	1.5
+++ drivers/maple/maple.c	2001/08/02 12:21:46
@@ -371,8 +371,7 @@
 
 	if (maple_packets>0) {
 		for (i=0; i<(1<<MAPLE_DMA_PAGES); i++)
-			__flush_wback_region(maple_sendbuf+i*PAGE_SIZE,
-					     maple_sendbuf+i*(PAGE_SIZE+1));
+			dma_cache_wback_inv(maple_sendbuf+i*PAGE_SIZE, PAGE_SIZE);
 		ctrl_outl(1, MAPLE_STATE);
 	}
 
Index: include/asm-sh/ide.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/ide.h,v
retrieving revision 1.15
diff -u -r1.15 ide.h
--- include/asm-sh/ide.h	2001/07/24 05:24:33	1.15
+++ include/asm-sh/ide.h	2001/08/02 12:21:48
@@ -26,10 +26,9 @@
 				unsigned long count)
 {
 	extern void _insw (unsigned long port, void *dst, unsigned long count);
-	void *end = dst + (count << 1);
 
 	_insw(port, dst, count);
-	__flush_wback_region(dst, end);
+	__flush_wback_region(dst, (count << 1));
 }
 #endif
 
Index: include/asm-sh/io.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io.h,v
retrieving revision 1.28
diff -u -r1.28 io.h
--- include/asm-sh/io.h	2001/07/27 06:09:47	1.28
+++ include/asm-sh/io.h	2001/08/02 12:21:48
@@ -465,11 +465,11 @@
  */
 
 #define dma_cache_wback_inv(_start,_size) \
-    cache_flush_area((unsigned long)(_start),((unsigned long)(_start)+(_size)))
+    __flush_purge_region(_start,_size)
 #define dma_cache_inv(_start,_size) \
-    cache_purge_area((unsigned long)(_start),((unsigned long)(_start)+(_size)))
+    __flush_invalidate_region(_start,_size)
 #define dma_cache_wback(_start,_size) \
-    cache_wback_area((unsigned long)(_start),((unsigned long)(_start)+(_size)))
+    __flush_wback_region(_start,_size)
 
 #endif /* __KERNEL__ */
 #endif /* __ASM_SH_IO_H */
Index: include/asm-sh/pgtable.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pgtable.h,v
retrieving revision 1.38
diff -u -r1.38 pgtable.h
--- include/asm-sh/pgtable.h	2001/07/30 07:24:01	1.38
+++ include/asm-sh/pgtable.h	2001/08/02 12:21:48
@@ -46,6 +46,7 @@
 #define p3_cache_init()				do { } while (0)
 #define __flush_dcache_region(start, end)	do { } while (0)
 #define __flush_wback_region(start, end)	do { } while (0)
+#define __flush_purge_region(start, end)	do { } while (0)
 
 #elif defined(__SH4__)
 /*
@@ -63,11 +64,14 @@
 #define flush_page_to_ram(page)			do { } while (0)
 #define flush_icache_page(vma,pg)		do { } while (0)
 
-/* Flush a region (smaller than a page) */
-extern void __flush_wback_region(void *start, void *end);
+/* Flush (write-back only) a region (smaller than a page) */
+extern void __flush_wback_region(void *start, int size);
+/* Flush (write-back & invalidate) a region (smaller than a page) */
+extern void __flush_purge_region(void *start, int size);
 
 /* Flush a page */
 extern void __flush_cache_page(unsigned long phys, int exec);
+extern void __flush_icache_page(unsigned long u0, unsigned long phys);
 
 /* Initialization of P3 area for copy_user_page */
 extern void p3_cache_init(void);

Re: [linuxsh-dev] Cache coherency issue

[SUGIOKA T. <su...@it...>]

At 14:40 01/08/02 +0900, NIIBE Yutaka <gn...@m1...> wrote:
>--- arch/sh/mm/cache-sh4.c	2001/07/28 15:12:46	1.7
>+++ arch/sh/mm/cache-sh4.c	2001/08/02 05:28:39
>@@ -420,7 +444,8 @@
> {
> 	if (((address ^ (unsigned long)to) & CACHE_ALIAS) == 0) {
> 		copy_page(to, from);
>-		__flush_wback_region(to, to+PAGE_SIZE);
>+		__flush_invalidate_region(from, PAGE_SIZE);
>+		__flush_wback_region(to, PAGE_SIZE);
> 	} else {
> 		pgprot_t pgprot = __pgprot(_PAGE_PRESENT | 
> 					   _PAGE_RW | _PAGE_CACHABLE |

>--- arch/sh/mm/__copy_user_page-sh4.S	2001/07/28 14:22:06	1.2
>+++ arch/sh/mm/__copy_user_page-sh4.S	2001/08/02 05:28:39
>@@ -44,7 +44,9 @@
> 	mov.l	@r11+,r4
> 	mov.l	@r11+,r5
> 	mov.l	@r11+,r6
>-	mov.l	@r11+,r7
>+	mov.l	@r11,r7
>+	ocbi	@r11
>+	add	#4,r11
> 	movca.l	r0,@r10
> 	add	#32,r10
> 	mov.l	r7,@-r10

It seems to me that if we use __flush_purge_region()/ocbp here instead of
__flush_invalidate_region()/ocbi then the change of mm/memory.c is not needed.

Isn't it?


----
SUGIOKA Toshinobu

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Paul M. <pm...@mv...>]

On Wed, Aug 01, 2001 at 09:32:29PM +1000, Greg Banks wrote:
>   So, when 2.5 is released, we start up a second drop-in tree
> for 2.5.x, while keeping the first 2.4.x drop-in tree?
>=20
>   What happens if 2.5.x is released before this gets organised (a real
> possibility)?  Do we then generate two seperate drop-in trees?
>=20
This is just a matter of maintaining two drop-in trees. They could just
be tagged as development and stable branches and be dealt with accordingly
under CVS. The PPC tree uses the same sort of convention, except they don't
do drop-in trees, and they use BitKeeper for source control.

This isn't really that big of a deal.. the best way to do it would be to ha=
ve
one person handling the stable, and someone else handling the experimental.
Either way, dealing with a drop-in tree cuts down maintenance time drastica=
lly.

When Linus drops a new tree on kernel.org, you simply look at the changes t=
hat
effect the files in the drop-in tree, and update them accordingly. This is
definately much less of a hassle then having to push forward the entire tre=
e,
as only the files that we're concerned about get modified.

In addition to this, it might be useful to start using proper CVS branches
and tags in CVS to make maintenance and such easier. ie, everything can be
under the same module in CVS, and newer revisions are simply inserted under
their own tag on their respective branch.. with the head always pointing to
the current stable.

> > Now the argument may be "why abandon the current full kernel tree then?=
"=20
>=20
>   I think the argument is "how can we make a drop-in tree workable for us=
?".
>=20
You would have to think long and hard about any disadvantages to a drop-in
tree that you wouldn't have to an entire tree. With the drop-in tree design,
you only ever touch that which is necessary to be modified by the tree. The=
re
is no reason to track other changes in the tree, as they don't concern the
tree, and are just a wasted effort.

> > As long as the drop-in tree can be easily sync'd with mainline patchlev=
els,
>=20
>   I don't see how.  It will require someone -- almost certainly Niibe-san=
 --
> to do frequent time-consuming merges.  Just like he does now.  The differ=
ence
> is that the final check-in will be much smaller.
>=20
Manual merging should be nothing short of a last resort. CVS deals with
branch merging just fine for the most part, and the few rejects it leaves
can be cleaned up by hand afterwards. It's totally counter productive to do
merges by hand of everything when the source control tool can deal with the
majority of it for you.

> > I'm going to ask James Simmons of ruby and linux-mips how he keeps his
> > trees in sync with the mainline kernel.  Paul M., if you're reading thi=
s,
> > do you have any suggestions regarding this?
>=20
>   Good idea.
>=20
I'd say just let CVS do its job, fix by hand that which CVS can't deal with,
and keep everything sanely tagged and under the proper branch. Maintaining
multiple revisions of something under a module in CVS isn't anywhere near
as complicated as people seem to think, after all, it's what CVS was design=
ed
for.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

[linuxsh-dev] Cache coherency issue

[NIIBE Y. <gn...@m1...>]

NIIBE Yutaka wrote:
 > We need cache flushing when process forks.  I think that this is the
 > bug in the mainline, I'll send a report to lkml (or MM-Bugzilla?).
 > When we forks, we set COW (copy-on-write) page to be write protected.
 > When doing that, we need to flush the cache (at least for SH-4, 
 > which has write-back cache). 

Sorry, this part is bogus, because before calling copy_page_range, 
dum_mmap calles flush_cache_mm, which flushes all the cache for the
process.  Please ignore this part (mm/memory.c).

Only this one, please:
 > Besides, in order to not having the alias absolutely, (1) I've changed
 > the use of __flush_wback_region for I/O into __flush_purge_region, and
 > (2) I've changed copy_user_page function so that it doesn't remain
 > data fetched.  This change does no harm for current implementation, 
 > but it is required by forthcoming change.
-- 

[linuxsh-dev] Cache coherency issue

[NIIBE Y. <gn...@m1...>]

We need cache flushing when process forks.  I think that this is the
bug in the mainline, I'll send a report to lkml (or MM-Bugzilla?).
When we forks, we set COW (copy-on-write) page to be write protected.
When doing that, we need to flush the cache (at least for SH-4, 
which has write-back cache). 

Besides, in order to not having the alias absolutely, (1) I've changed
the use of __flush_wback_region for I/O into __flush_purge_region, and
(2) I've changed copy_user_page function so that it doesn't remain
data fetched.  This change does no harm for current implementation, 
but it is required by forthcoming change.

With old implementation, problem occurs (it's quite rare, though) like
this.

 (1) Say, a process read the variable at .data section.
     Read I/O request on the page are issued (say, it's to IDE driver).
 (2) IDE driver issues the command to the disk, and get the
     result.  (See the `insw' implementation in asm-sh/ide.h.)
     By insw, the data goes to the memory with __flush_wback_range.
     (*** It should be __flush_purge_range. ***)
 (3) The page is mapped to the process.  Supporse a process
     write to the page after that.
     Then, the process forks.  The page is set to be write-protected, 
     to be COW.  (*** Here, we need to flush the page so that
     user process data goes to memory ***)
 (4) The forked process writes to the variable.  COW page-handling
     occurs here.  The original page is copied to new page.
     But if the cache entry of (2) still remains, the process
     sees the bogus data on the cache, not accessing the memory.

2001-08-02  NIIBE Yutaka  <gn...@m1...>

	* mm/memory.c (copy_page_range): Write back the cache before we
	set PTE read-protect.
	* arch/sh/mm/cache-sh4.c (copy_user_page): Invalidate the cache,
	which is used to read the data from FROM.  Let cache not to have
	data.
	* arch/sh/mm/__copy_user_page-sh4.S (__copy_user_page): Likewise.

	* drivers/maple/maple.c (maple_send): Call dma_cache_wback_inv.
	(was: __flush_wback_region).

	* include/asm-sh/io.h (dma_cache_wback_inv, dma_cache_inv,
	dma_cache_wback): Defined with new __flush_XXX_region functions.
	(was: bogus cache_XXX_area functions, not implemented).

	* drivers/cdrom/gdrom.c (gdrom_intr): Call __flush_purge_region
	instead of __flush_wback_region.
	* include/asm-sh/ide.h (ide_insw): Likewise.

	* arch/sh/mm/cache-sh4.c (__flush_purge_region): New function.
	(__flush_wback_region, __flush_invalidate_region): Last argument
	is SIZE (was: END).
	* include/asm-sh/pgtable.h (__flush_purge_region): Added.

Index: arch/sh/mm/__copy_user_page-sh4.S
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/__copy_user_page-sh4.S,v
retrieving revision 1.2
diff -u -r1.2 __copy_user_page-sh4.S
--- arch/sh/mm/__copy_user_page-sh4.S	2001/07/28 14:22:06	1.2
+++ arch/sh/mm/__copy_user_page-sh4.S	2001/08/02 05:28:39
@@ -44,7 +44,9 @@
 	mov.l	@r11+,r4
 	mov.l	@r11+,r5
 	mov.l	@r11+,r6
-	mov.l	@r11+,r7
+	mov.l	@r11,r7
+	ocbi	@r11
+	add	#4,r11
 	movca.l	r0,@r10
 	add	#32,r10
 	mov.l	r7,@-r10
Index: arch/sh/mm/cache-sh4.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/cache-sh4.c,v
retrieving revision 1.7
diff -u -r1.7 cache-sh4.c
--- arch/sh/mm/cache-sh4.c	2001/07/28 15:12:46	1.7
+++ arch/sh/mm/cache-sh4.c	2001/08/02 05:28:39
@@ -125,12 +125,14 @@
  *
  * START, END: Virtual Address (U0, P1, or P3)
  */
-void __flush_wback_region(void *start, void *end)
+void __flush_wback_region(void *start, int size)
 {
 	unsigned long v;
+	unsigned long begin, end;
 
-	for (v = (unsigned long)start& ~(L1_CACHE_BYTES-1);
-	     v < (unsigned long)end; v+=L1_CACHE_BYTES) {
+	begin = (unsigned long)start& ~(L1_CACHE_BYTES-1);
+	end = begin + size;
+	for (v = begin; v < end; v+=L1_CACHE_BYTES) {
 		asm volatile("ocbwb	%0"
 			     : /* no output */
 			     : "m" (__m(v)));
@@ -138,14 +140,36 @@
 }
 
 /*
+ * Write back the dirty D-caches and invalidate them.
+ *
+ * START, END: Virtual Address (U0, P1, or P3)
+ */
+void __flush_purge_region(void *start, int size)
+{
+	unsigned long v;
+	unsigned long begin, end;
+
+	begin = (unsigned long)start& ~(L1_CACHE_BYTES-1);
+	end = begin + size;
+	for (v = begin; v < end; v+=L1_CACHE_BYTES) {
+		asm volatile("ocbp	%0"
+			     : /* no output */
+			     : "m" (__m(v)));
+	}
+}
+
+
+/*
  * No write back please
  */
-void __flush_invalidate_region(unsigned long start, unsigned long end)
+void __flush_invalidate_region(void *start, int size)
 {
 	unsigned long v;
+	unsigned long begin, end;
 
-	start &= ~(L1_CACHE_BYTES-1);
-	for (v = start; v < end; v+=L1_CACHE_BYTES) {
+	begin = (unsigned long)start& ~(L1_CACHE_BYTES-1);
+	end = begin + size;
+	for (v = begin; v < end; v+=L1_CACHE_BYTES) {
 		asm volatile("ocbi	%0"
 			     : /* no output */
 			     : "m" (__m(v)));
@@ -383,7 +407,7 @@
 {
 	if (((address ^ (unsigned long)to) & CACHE_ALIAS) == 0) {
 		clear_page(to);
-		__flush_wback_region(to, to+PAGE_SIZE);
+		__flush_wback_region(to, PAGE_SIZE);
 	} else {
 		pgprot_t pgprot = __pgprot(_PAGE_PRESENT | 
 					   _PAGE_RW | _PAGE_CACHABLE |
@@ -420,7 +444,8 @@
 {
 	if (((address ^ (unsigned long)to) & CACHE_ALIAS) == 0) {
 		copy_page(to, from);
-		__flush_wback_region(to, to+PAGE_SIZE);
+		__flush_invalidate_region(from, PAGE_SIZE);
+		__flush_wback_region(to, PAGE_SIZE);
 	} else {
 		pgprot_t pgprot = __pgprot(_PAGE_PRESENT | 
 					   _PAGE_RW | _PAGE_CACHABLE |
Index: arch/sh/mm/init.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/arch/sh/mm/init.c,v
retrieving revision 1.17
diff -u -r1.17 init.c
--- arch/sh/mm/init.c	2001/07/24 05:24:33	1.17
+++ arch/sh/mm/init.c	2001/08/02 05:28:39
@@ -144,7 +144,7 @@
 
 	/* clear the zero-page */
 	memset(empty_zero_page, 0, PAGE_SIZE);
-	__flush_wback_region(empty_zero_page, empty_zero_page+PAGE_SIZE);
+	__flush_wback_region(empty_zero_page, PAGE_SIZE);
 
 	/* this will put all low memory onto the freelists */
 	totalram_pages += free_all_bootmem_node(NODE_DATA(0));
Index: drivers/cdrom/gdrom.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/cdrom/gdrom.c,v
retrieving revision 1.2
diff -u -r1.2 gdrom.c
--- drivers/cdrom/gdrom.c	2001/07/31 07:03:58	1.2
+++ drivers/cdrom/gdrom.c	2001/08/02 05:28:40
@@ -144,7 +144,7 @@
 		}
 
 		insw(GDROM_DATA, ctrl->buf, count/2); 
-		__flush_wback_region(ctrl->buf, ctrl->buf + count);
+		__flush_purge_region(ctrl->buf, count);
 		ctrl->buf += count;
 		ctrl->size -= count;
 	}
Index: drivers/maple/maple.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/drivers/maple/maple.c,v
retrieving revision 1.5
diff -u -r1.5 maple.c
--- drivers/maple/maple.c	2001/07/30 13:01:42	1.5
+++ drivers/maple/maple.c	2001/08/02 05:28:41
@@ -371,8 +371,7 @@
 
 	if (maple_packets>0) {
 		for (i=0; i<(1<<MAPLE_DMA_PAGES); i++)
-			__flush_wback_region(maple_sendbuf+i*PAGE_SIZE,
-					     maple_sendbuf+i*(PAGE_SIZE+1));
+			dma_cache_wback_inv(maple_sendbuf+i*PAGE_SIZE, PAGE_SIZE);
 		ctrl_outl(1, MAPLE_STATE);
 	}
 
Index: include/asm-sh/ide.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/ide.h,v
retrieving revision 1.15
diff -u -r1.15 ide.h
--- include/asm-sh/ide.h	2001/07/24 05:24:33	1.15
+++ include/asm-sh/ide.h	2001/08/02 05:28:46
@@ -26,10 +26,9 @@
 				unsigned long count)
 {
 	extern void _insw (unsigned long port, void *dst, unsigned long count);
-	void *end = dst + (count << 1);
 
 	_insw(port, dst, count);
-	__flush_wback_region(dst, end);
+	__flush_purge_region(dst, (count << 1));
 }
 #endif
 
Index: include/asm-sh/io.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/io.h,v
retrieving revision 1.28
diff -u -r1.28 io.h
--- include/asm-sh/io.h	2001/07/27 06:09:47	1.28
+++ include/asm-sh/io.h	2001/08/02 05:28:46
@@ -465,11 +465,11 @@
  */
 
 #define dma_cache_wback_inv(_start,_size) \
-    cache_flush_area((unsigned long)(_start),((unsigned long)(_start)+(_size)))
+    __flush_purge_region(_start,_size)
 #define dma_cache_inv(_start,_size) \
-    cache_purge_area((unsigned long)(_start),((unsigned long)(_start)+(_size)))
+    __flush_invalidate_region(_start,_size)
 #define dma_cache_wback(_start,_size) \
-    cache_wback_area((unsigned long)(_start),((unsigned long)(_start)+(_size)))
+    __flush_wback_region(_start,_size)
 
 #endif /* __KERNEL__ */
 #endif /* __ASM_SH_IO_H */
Index: include/asm-sh/pgtable.h
===================================================================
RCS file: /cvsroot/linuxsh/kernel/include/asm-sh/pgtable.h,v
retrieving revision 1.38
diff -u -r1.38 pgtable.h
--- include/asm-sh/pgtable.h	2001/07/30 07:24:01	1.38
+++ include/asm-sh/pgtable.h	2001/08/02 05:28:46
@@ -46,6 +46,7 @@
 #define p3_cache_init()				do { } while (0)
 #define __flush_dcache_region(start, end)	do { } while (0)
 #define __flush_wback_region(start, end)	do { } while (0)
+#define __flush_purge_region(start, end)	do { } while (0)
 
 #elif defined(__SH4__)
 /*
@@ -63,8 +64,10 @@
 #define flush_page_to_ram(page)			do { } while (0)
 #define flush_icache_page(vma,pg)		do { } while (0)
 
-/* Flush a region (smaller than a page) */
-extern void __flush_wback_region(void *start, void *end);
+/* Flush (write-back only) a region (smaller than a page) */
+extern void __flush_wback_region(void *start, int size);
+/* Flush (write-back & invalidate) a region (smaller than a page) */
+extern void __flush_purge_region(void *start, int size);
 
 /* Flush a page */
 extern void __flush_cache_page(unsigned long phys, int exec);
Index: mm/memory.c
===================================================================
RCS file: /cvsroot/linuxsh/kernel/mm/memory.c,v
retrieving revision 1.36
diff -u -r1.36 memory.c
--- mm/memory.c	2001/07/31 00:05:21	1.36
+++ mm/memory.c	2001/08/02 05:28:47
@@ -227,6 +227,10 @@
 				if (cow) {
 					ptep_set_wrprotect(src_pte);
 					pte = *src_pte;
+#if 1 /* For write-back cache system which has alias issues, we need to
+       * flush the cache before COW */
+					flush_cache_page(vma, address);
+#endif
 				}
 
 				/* If it's a shared mapping, mark it clean in the child */
-- 

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[M. R. B. <mr...@0x...>]

* Greg Banks <gb...@po...> on Wed, Aug 01, 2001:

> 
>   So, when 2.5 is released, we start up a second drop-in tree
> for 2.5.x, while keeping the first 2.4.x drop-in tree?

Yes, because 2.4.x will still continue to be maintained and upgraded, and
we'll have to remain on our toes to fix breakage.

> 
>   What happens if 2.5.x is released before this gets organised (a real
> possibility)?  Do we then generate two seperate drop-in trees?
> 

Well, I'm working on getting the list together of files that are affected
by the move.  I still think that we'll benefit from a drop-in tree with 2.4
code as well as 2.5, so yeah, I'd be willing to continue to reorganize 2.4
if that happened.

Don't jinx me though :).

> > Now the argument may be "why abandon the current full kernel tree then?" 
> 
>   I think the argument is "how can we make a drop-in tree workable for us?".
> 

I almost have a *real* answer for this.

> > What *were* we gonna do when 2.5 hit, import that entire
> > tree into CVS?
> 
>   No idea.  But I wanted to hear *your* ideas.
> 

Oh, I was wondering if anyone else had thought of that.  My idea is to
simply start a new drop-in tree.

> 
>   The two main reasons are
> 
> 1.  SH hardware behaves slightly differently from x86 and lots of other
>     platforms and this causes changes that are harmless on those platforms
>     to break LinuxSH.  I'm thinking of the cache here.
> 
> 2.  LinuxSH depends (in both obvious and subtle ways) on functionality and
>     behaviour in the kernel which mutates from release to release.  This
>     is of course a problem with any port.
> 
[...]
> 
>   It's not every change that breaks LinuxSH, it's one of the several dozen
> which make up a release.  This sort of hassle is pretty much inevitable
> when any large body of software depends so intricately on another.
> 
>   This is why the merging is a manual process.
> 

Thanks for the heads-up.

> 
>   I don't see how.  It will require someone -- almost certainly Niibe-san --
> to do frequent time-consuming merges.  Just like he does now.  The difference
> is that the final check-in will be much smaller.
>

Yes, and working with the smaller subset of files helps to ease that process.

> 
> > When I come up with some technical answers, I'll post them here and write
> > them in a set of guidlines (part of the developers guidelines perhaps?).
> 
>   I'm looking forward to it.
> 

I have the procedures to maintain the new tree, I just have to go through
them to make sure they work :).  I'll be posting instructions soon.

> 
>   This seems unnecessarily complex, for a handful of files in each directory.
> How about
> 
> arch/sh/cchips/hd6446x/
> 

That's fine.

M. R.

[linuxsh-dev] Re: SH4. Problem with floating point operations. using sh4-linux-gcc

[kaz K. <kk...@rr...>]

Hi,

I've talked about FCNVSD problem with Amir Hader.

Amir Hadar <ami...@is...> wrote:
> How do I use floating point emulation. The sh4-linux-gcc doesn't 
> recognize -msoft-float option. Is there an already made module that I 
> can linkup with my project that catches the SIGFPE and do the emulation? 
> What other workaround can do to support full denormelized floats and 
> doubles?

There is no such module yet, as I know. The emulation itself
isn't hard. Attached code is for the experimental emulation.
But this isn't working code in the current kernel. Hacking
kernel will be needed to implement such emulation in the kernel
and I have no idea for other workaround.
Of course, an awful workaround is to test float whether it's
denormalized or not in userland and if it's denormalized, then
construct valid double value by hand (as denormal_to_double ()
does), though nobody will do it.

	kaz
--
static void
denormal_to_double (struct pt_regs *regs, unsigned long x, int n)
{
  unsigned long du, dl;
  int exp = 1023 - 126;

  if (x != 0 && (x & 0x7f800000) == 0)
    {
      du = (x & 0x80000000);
      while ((x & 0x00800000) == 0)
        {
          x <<= 1;
          exp--;
        }
      x &= 0x007fffff;
      du |= (exp << 20) | (x >> 3);
      dl = x << 29;

      regs->fpregs[n] = du;
      regs->fpregs[n+1] = dl;
    }
}

static int
ieee_fpe_handler (struct pt_regs *regs)
{
  unsigned short insn = *(unsigned short *) regs->pc;
  unsigned short finsn;
  unsigned long nextpc;
  int nib[4]
    = { (insn >> 12) & 0xf, (insn >> 8) & 0xf, (insn >> 4) & 0xf, insn & 0xf};

  if (nib[0] == 0xb ||
      (nib[0] == 0x4 && nib[2] == 0x0 && nib[3] == 0xb)) /* bsr & jsr */
    regs->pr = regs->pc + 4;
  
  if (nib[0] == 0xa || nib[0] == 0xb)  /* bra & bsr */
    {
      nextpc = regs->pc + 4 + ((short) ((insn & 0xfff) << 4) >> 3);
      finsn = *(unsigned short *) (regs->pc + 2);
    }
  else if (nib[0] == 0x8 && nib[1] == 0xd) /* bt/s */
    {
      if (regs->sr & 1)
	nextpc = regs->pc + 4 + ((char) (insn & 0xff) << 1);
      else
	nextpc = regs->pc + 4;
      finsn = *(unsigned short *) (regs->pc + 2);
    }
  else if (nib[0] == 0x8 && nib[1] == 0xf) /* bf/s */
    {
      if (regs->sr & 1)
	nextpc = regs->pc + 4;
      else
	nextpc = regs->pc + 4 + ((char) (insn & 0xff) << 1);
      finsn = *(unsigned short *) (regs->pc + 2);
    }
  else if (nib[0] == 0x4 && nib[3] == 0xb &&
      (nib[2] == 0x0 || nib[2] == 0x2)) /* jmp & jsr */
    {
      nextpc = regs->regs[nib[1]];
      finsn = *(unsigned short *) (regs->pc + 2);
    }
  else if (nib[0] == 0x0 && nib[3] == 0x3 &&
      (nib[2] == 0x0 || nib[2] == 0x2)) /* braf & bsrf */
    {
      nextpc = regs->pc + 4 + regs->regs[nib[1]];
      finsn = *(unsigned short *) (regs->pc + 2);
    }
  else if (insn == 0x000b) /* rts */
    {
      nextpc = regs->pr;
      finsn = *(unsigned short *) (regs->pc + 2);
    }
  else
    {
      nextpc = regs->pc + 2;
      finsn = insn;
    }

  if ((finsn & 0xf1ff) == 0xf0ad
      && (regs->fpscr & (1 << 17))) /* fcnvsd & FPU error */
    {
      denormal_to_double (regs, regs->fpul, (finsn >> 8) & 0xf);
      regs->fpscr &= ~(FPSCR_CAUSE_MASK | FPSCR_FLAG_MASK);
      regs->pc = nextpc;
      return 1;
    }

  return 0;
}

Re: [linuxsh-dev] Quick note about drop-in trees

[Greg B. <gb...@po...>]

"M. R. Brown" wrote:
> 
> * Greg Banks <gb...@po...> on Wed, Aug 01, 2001:
> 
> > Also the exact version involved needs
> > to be noted somewhere and maintained as part of the merge procedure.
> >
> 
> The convention I've seen in other drop-in trees is a file named
> 'AGAINST-2.4.7'.  That file is just touched.

  Sounds good.

>  BTW, I thought that the
> massive CVS tree was constrained to only one version :).

  Yes, of course.  But it's self-contained so the issue of managing
which mainline version it's derived from is moot.

> >   Now, does the drop-in tree get dumped on top of the mainline tree
> > or does it go into a sibling directory? [...]
> 
> The treelink.sh script (attached to this e-mail) symlinks the drop-in tree
> on top of the mainline tree.  So you always update from the orginal drop-in
> tree and rerun treelink.sh.  This is simple enough for the passive developer
> to do when the kernel is upgraded and the drop-in tree is re-sync'd.

  Ok, I'll take a look at it.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] Quick note about drop-in trees

[M. R. B. <mr...@0x...>]

* Greg Banks <gb...@po...> on Wed, Aug 01, 2001:

Ok, I'm supposed to be going to bed, but I just saw your post :).

> 
>   Right.  This has the effect that the drop-in tree works with exactly
> one version of the mainline tree.  This fact needs to be stated in an
> obvious place so that people checking out the drop-in tree don't do
> the wrong thing accidentally.  Also the exact version involved needs
> to be noted somewhere and maintained as part of the merge procedure.
> 

The convention I've seen in other drop-in trees is a file named
'AGAINST-2.4.7'.  That file is just touched.  BTW, I thought that the
massive CVS tree was constrained to only one version :).

> 
>   Now, does the drop-in tree get dumped on top of the mainline tree
> or does it go into a sibling directory?  Both approaches have major
> problems.  On-top ends up with massive '?' results from "cvs -n up".
> Sibling has problems with Makefiles (not solved until kaos' new kbuild).
> 

The treelink.sh script (attached to this e-mail) symlinks the drop-in tree
on top of the mainline tree.  So you always update from the orginal drop-in
tree and rerun treelink.sh.  This is simple enough for the passive developer
to do when the kernel is upgraded and the drop-in tree is re-sync'd.

I've never used a sibling tree so I haven't a clue how that works.

Ok, now I'm *really* going to bed :).

C'ya.

Marcus

Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Greg B. <gb...@po...>]

"M. R. Brown" wrote:
> 
> Well, I'm willing to be a bit more ambitious and commit to getting the
> current tree restructured, not waiting for 2.5.  Sure it will take a lot of
> effort, but I think it will be beneficial in the long run.  For August I
> have basically unlimited free time to commit to working on this.  I can
> come up with a strategy for restructuring, when I get that finished I'll
> send it to the list for approval, is that ok?

  I'm looking forward to it.

> I can do my work on restructuring the tree in parallel with current LinuxSH
> development.  The current LinuxSH code is based in the kernel/ CVS
> directory, I can start the restructuring work in a directory called linux/
> at the same time.
> 
> >
> > (1) "Patch Manager"
> > We have "Patch Manager", but it's almost non-functional (no one care
> > it).  I think that the future direction is remove using "Patch
> > Manager" and require people to send all the changes to review.

  Yes, sf's Patch Manager appears pretty much superfluous.  We can't
turn it off AFAIK, so we need to make sure people know not to use it.

> I think that's a good idea.  One more thing I wanted to point out but I
> forgot: in the mailing list section on the LinuxSH SF website, it mentions
> the linux-sh and linux-sh-ja mailing lists, but neglects to mention the
> linuxsh-dev and linuxsh-cvs lists.  When I first looked at LinuxSH, I
> didn't realize that those lists existed, and I missed a good deal of
> discussion that only took place on the linuxsh-dev list.  Could someone
> update that section to add those lists?

  Actually, I deliberately left lin...@sf... out because I was 
under the impression (apparently false) that it was nearly unused.  Also
it seems to me that it offers little advantage over or differentiation
from the m17n.org list which it was meant to replace but which hasn't died.
Frankly I think it should be killed off.

  As for linuxsh-cvs, it's there already.  Perhaps you need to scroll down.

> [...]  That's the advantage of using a
> drop-in tree as opposed to including the entire kernel source in CVS - if
> there is a "global" mainline change that somehow breaks LinuxSH
> functionality, all you have to do is fix that relevant portion in the
> drop-in tree - you don't have to patch everything.

  Hah, if only it were so easy.  A drop-in tree is a good idea but
this is not a good reason for it.

> It should be easy to pick out individual patches that target LinuxSH code
> if that code comes from external sources.  I believe the package named
> 'patchutils' (in Debian) allows you to pick out individual patches within a
> patchset.

  The problems arise when subtle things change in the mainline which
are apparently unrelated to LinuxSH code but break it.  For example,
subtle behaviours of remap_page_range() changed between 2.4.0-test10
and 2.4.0, breaking my PCMCIA code.

> 
> > (3) Testing
> > It would be good if we can maintain some sort of success/failure table
> > with version and/or date.  It is good for tracking bug introduced.
> > Performance test is also good.
> 
> That's a great idea :).

  DGI (Damn Good Idea).

  Actually this was idea we had back in Mar 2000 but never got around
to implementing.  The dream was to have some kind of database attached
to the SF website which people could update.  Perhaps a less hi-tech
approach would succeed ;-)

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

Re: [linuxsh-dev] Quick note about drop-in trees

[Greg B. <gb...@po...>]

"M. R. Brown" wrote:
> 
> Let me clarify a bit how a drop-in tree should handle changes from mainline
> - just in case there are still some questions or concerns about keeping the
> code synced.
> 
> Obviously all code local to LinuxSH lives in the drop-in tree.  But what
> about changes that we make to the mainline code that sits outside of our
> realm?  Here's a quick idea of how we could do this:
> 
> - The drop-in tree is designed to supercede the mainline kernel, because
>   we're dealing with experimental code in the first place.  So any files
>   that we touch that live in the mainline have to go into the drop-in tree.
> 
> - Say we make a change to drivers/net/8139too.c (e.g. add Dreamcast BBA
>   support, completely local to LinuxSH).  We copy (add/commit) that file
>   into the drop-in tree, and make our changes there.
> 
> - If the 8139too driver is modified by its maintainer, who sends patches to
>   mainline for the next -pre patchlevel then it's our responsiblity to
>   merge the mainline patches with our drop-in version.

  Right.  This has the effect that the drop-in tree works with exactly
one version of the mainline tree.  This fact needs to be stated in an
obvious place so that people checking out the drop-in tree don't do
the wrong thing accidentally.  Also the exact version involved needs
to be noted somewhere and maintained as part of the merge procedure.

> 
> - When the code has been tested sufficently, we can contact the maintainer
>   and send him patches so that she can send them back to the mainline.
> 
> - Unless the driver needs another change, it has been completely sync'd to
>   mainline and any further changes from mainline can simply be patched
>   against the driver.
> 
> Even the mainline code (outside of LinuxSH) that we affect is negligible,
> so the drop-in tree still remains considerable smaller than the entire
> kernel tree.

  Sure, and this is it's primary attraction.

  Now, does the drop-in tree get dumped on top of the mainline tree
or does it go into a sibling directory?  Both approaches have major
problems.  On-top ends up with massive '?' results from "cvs -n up".
Sibling has problems with Makefiles (not solved until kaos' new kbuild).

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.

[linuxsh-dev] Quick note about drop-in trees

[M. R. B. <mr...@0x...>]

Let me clarify a bit how a drop-in tree should handle changes from mainline
- just in case there are still some questions or concerns about keeping the
code synced.

Obviously all code local to LinuxSH lives in the drop-in tree.  But what
about changes that we make to the mainline code that sits outside of our
realm?  Here's a quick idea of how we could do this:

- The drop-in tree is designed to supercede the mainline kernel, because
  we're dealing with experimental code in the first place.  So any files
  that we touch that live in the mainline have to go into the drop-in tree.

- Say we make a change to drivers/net/8139too.c (e.g. add Dreamcast BBA
  support, completely local to LinuxSH).  We copy (add/commit) that file
  into the drop-in tree, and make our changes there.

- If the 8139too driver is modified by its maintainer, who sends patches to
  mainline for the next -pre patchlevel then it's our responsiblity to
  merge the mainline patches with our drop-in version.

- When the code has been tested sufficently, we can contact the maintainer
  and send him patches so that she can send them back to the mainline.

- Unless the driver needs another change, it has been completely sync'd to
  mainline and any further changes from mainline can simply be patched
  against the driver.

Even the mainline code (outside of LinuxSH) that we affect is negligible,
so the drop-in tree still remains considerable smaller than the entire
kernel tree.

For examples of this, please check out the linuxconsole ruby tree
(http://sf.net/projects/linuxconsole) or linux-mips tree
(http://sf.net/projects/linux-mips).

Any problems with this approach?

Marcus