On Fri, 09 Mar 2001, Rogier Wolff wrote:
>Jesse Pollard wrote:
>> On Fri, 09 Mar 2001, Graham Murray wrote:
>> >"Mohammad A. Haque" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
