All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <jesse@cats-chateau.net>
To: R.E.Wolff@BitWizard.nl (Rogier Wolff)
Cc: Graham Murray <graham@webwayone.com>, linux-kernel@vger.kernel.org
Subject: Re: Microsoft begining to open source Windows 2000?
Date: Fri, 9 Mar 2001 20:10:50 -0600	[thread overview]
Message-ID: <01030920140700.10781@tabby> (raw)
In-Reply-To: <200103091247.NAA31936@cave.bitwizard.nl>
In-Reply-To: <200103091247.NAA31936@cave.bitwizard.nl>

On Fri, 09 Mar 2001, Rogier Wolff wrote:
>Jesse Pollard wrote:
>> On Fri, 09 Mar 2001, Graham Murray wrote:
>> >"Mohammad A. Haque" <mhaque@haque.net> writes:
>> >
>> >> making a patch means you've modfied the source which you are not allowed
>> >> to do. The most you can do is report the bug through normal channels
>> >> (you dont even have priority in reporting bugs since you have the code).
>> >
>> >Does making a patch necessarily require modifying the source code?
>> >Back in my days as a mainframe systems programmer (ICL VME/B), most OS
>> >patches were made to the binary image, either in the file or to the
>> >loaded virtual memory image.
>
>> Nearly always. The problem is that the patch may make the module
>> bigger/smaller or relocate variables whose address then changes. All
>> locations that these are referenced must be modified (either direct
>> address or offset).  Sometimes other modules will get relocated too.
>
>You're too young. Or I'm too old. :-)

Neither - we've both been there.
>
>IF your patch can be inserted into the code space available: Then good. 
>If not, you move the code out of the previously allocated space, and
>put it somewhere else. Put a "jump" instruction in the old place. 
>

Only if you generate your patch in assembler.... and there is somewhere
else to put the real module...

>At the university there was a lab-assignment where we had to use the
>provided semaphore routines. Turns out we found a bug. The TA then
>told us it was going to be hard-to-fix, as about 8192 bytes of the 8k
>PROM were in use. He was wrong. The bug was one instruction too
>many. We just wrote "nop" over the bad instruction. The processor had
>also been correctly designed: you could overwrite any instruction in
>the PROM with "nop", as the NOP instruction was 0xff. Fixed on the
>spot!
>

Congratulations - We used to do similar things to change the baud
rate of serial interfaces (though overwriting core memory was much
easier).
-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: jesse@cats-chateau.net

Any opinions expressed are solely my own.

  reply	other threads:[~2001-03-10  2:15 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-08 16:04 Microsoft begining to open source Windows 2000? Venkatesh Ramamurthy
2001-03-08 16:21 ` Rik van Riel
2001-03-08 16:28 ` Mohammad A. Haque
2001-03-08 18:07   ` Richard B. Johnson
2001-03-08 18:32   ` Joseph Pingenot
2001-03-09 10:40   ` Graham Murray
2001-03-09 12:05     ` Jesse Pollard
2001-03-09 12:47       ` Rogier Wolff
2001-03-10  2:10         ` Jesse Pollard [this message]
2001-03-09 13:26     ` Mohammad A. Haque
2001-03-09 17:01       ` Ralf Baechle
2001-03-09 19:34         ` Mohammad A. Haque
2001-03-08 16:31 ` Anton Altaparmakov
2001-03-08 17:36   ` James A. Sutherland
2001-03-08 17:53   ` Anton Altaparmakov
2001-03-08 19:14     ` Jeff V. Merkey
2001-03-09  3:35 ` Werner Almesberger
  -- strict thread matches above, loose matches on Subject: below --
2001-03-08 21:21 Jason Venner
2001-03-08 19:40 Venkatesh Ramamurthy
2001-03-08 16:49 Wayne.Brown
2001-03-08 15:24 Jesse Pollard
2001-03-08 18:34 ` Ian Stirling
2001-03-08 20:41   ` Jesse Pollard
2001-03-08 15:01 Venkatesh Ramamurthy
2001-03-08 15:52 ` Mohammad A. Haque
2001-03-08 16:06 ` Alan Cox
2001-03-09  5:43   ` J. Dow
2001-03-09  6:34     ` Mike Galbraith
2001-03-09 11:11       ` Dr. Michael Weller
2001-03-08 19:10 ` Roeland Th. Jansen
2001-03-08 19:38 ` Lars Gaarden
2001-03-09 18:16   ` Kai Henningsen
2001-03-10  3:49     ` Steve Underwood
2001-03-11 17:23     ` Mark H. Wood

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=01030920140700.10781@tabby \
    --to=jesse@cats-chateau.net \
    --cc=R.E.Wolff@BitWizard.nl \
    --cc=graham@webwayone.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.