Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Paul Bame <bame@endor.fc.hp.com>
To: parisc-linux@thepuffingroup.com
Subject: [parisc-linux] 2.3 whining
Date: Thu, 13 Jan 2000 08:43:40 -0700	[thread overview]
Message-ID: <E128mPU-0000c6-00@endor.fc.hp.com> (raw)
In-Reply-To: Your message of "Wed, 12 Jan 2000 20:48:58 EST." <387D2F0A.F41A4129@thepuffingroup.com>


A lot of code cleanup occurred and several defects were fixed in 2.2
since the beginning of December.  Much of this effort (my effort is
why I'm upset, and some good efforts by John David Angelin too) is now
gone.  The dirty code and defects, which *were* fixed, are now holding
us all back in 2.3!  Things could've been done better.

When the 2.3 CVS tree was started, it would've been better to copy the
RCS files (and tag the 2.2 ones) instead of checking in a newly-numbered
revision with no past
history attached.  Because of the way it was done, it's unnecessarily
difficult to tell which 2.2 file version was used to begin the
2.3 port (because all the versions are 1.1 again), and thus
difficult to figure out which changes need to be re-merged.  Also the
comments from the previous authors have been lost in the 2.3 tree.

In going to 2.3 the realmode embedded executable stuff I designed has
been obliterated.  I don't know how this was decided but I was not part
of the decision.  Even though it might be the right long-term answer,
consequently we now have fragile real-mode C code as we had before, so it
is not a simple matter to re-merge the 2.2 fixes into 2.3
because you're working against the compiler and some other structural
differences, leaving us with a nice mess.  (jsm thought up a nice
way to avoid my realmode hack, but I have no incentive to
start coding that to see it disappear too).

If my hacking is unhelpful to palinux, I would prefer knowing
that *before* making changes rather than finding out *after*
doing a bunch of work and watching it disappear.

I'm owed an explanation of why the realmode embedded executable
was wrong for the project and is now gone.
And an explanation of why the defects and improvements
I (and JDA) contributed were wrong for the project too.  I'm willing
to learn.

        -P

       reply	other threads:[~2000-01-13 16:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <387D2F0A.F41A4129@thepuffingroup.com>
2000-01-13 15:43 ` Paul Bame [this message]
2000-01-13 16:43   ` [parisc-linux] 2.3 whining Matthew Wilcox
2000-01-13 17:37     ` Paul Bame
2000-01-13 20:42 Tor Arntsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E128mPU-0000c6-00@endor.fc.hp.com \
    --to=bame@endor.fc.hp.com \
    --cc=parisc-linux@thepuffingroup.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox