mirror of
https://gitlab.rtems.org/rtems/rtos/rtems.git
synced 2026-11-09 08:37:58 +08:00
Remove (Generated files)
This commit is contained in:
Ralf Corsepius committed
1 parent
1d18ba4eee
commit
43fe862ae3
10 files changed
-1885
No files matched your search
File diff suppressed because it is too large.
Load diff
@@ -1,51 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
|
||||
@node BSP Questions, What is a BSP?, , Top
|
||||
|
||||
@chapter BSP Questions
|
||||
@ifinfo
|
||||
@menu
|
||||
* What is a BSP?::
|
||||
* What has to be in a BSP?::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
The items in this category provide answers to questions
|
||||
commonly asked about BSPs.
|
||||
|
||||
|
||||
@node What is a BSP?, What has to be in a BSP?, BSP Questions, BSP Questions
|
||||
|
||||
@section What is a BSP?
|
||||
|
||||
BSP is an acronym for Board Support Package.
|
||||
|
||||
A BSP is a collection of device drivers, startup code, linker scripts,
|
||||
and compiler support files (specs files) that tailor RTEMS for a
|
||||
particular target hardware environment.
|
||||
|
||||
|
||||
@node What has to be in a BSP?, , What is a BSP?, BSP Questions
|
||||
|
||||
@section What has to be in a BSP?
|
||||
|
||||
The basic set of items is the linker script, bsp_specs, and startup code.
|
||||
If you want standard IO, then you need a console driver. This is needed
|
||||
to run any of the RTEMS tests. If you want to measure passage of time,
|
||||
you need a clock tick driver. This driver is needed for all RTEMS tests
|
||||
EXCEPT hello world and the timing tests. The timer driver is a benchmark
|
||||
timer and is needed for the tmtests (timing tests). Sometimes you will
|
||||
see a shmsupp directory which is for shared memory multiprocessing
|
||||
systems. The network driver and real-time clock drivers are optional
|
||||
and not required by any RTEMS tests.
|
||||
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -1,31 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
|
||||
@node RTEMS Concepts, RTEMS Workspace versus Program Heap, , Top
|
||||
|
||||
@chapter RTEMS Concepts
|
||||
@ifinfo
|
||||
@menu
|
||||
* RTEMS Workspace versus Program Heap::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
The questions in this category are hints that help basic understanding.
|
||||
|
||||
|
||||
@node RTEMS Workspace versus Program Heap, , RTEMS Concepts, RTEMS Concepts
|
||||
|
||||
@section RTEMS Workspace versus Program Heap
|
||||
|
||||
The RTEMS Workspace is used to allocate space for objects created
|
||||
by RTEMS such as tasks, semaphores, message queues, etc.. It is
|
||||
primarily used during system initialization although task stacks
|
||||
and message buffer areas are also allocated from here.
|
||||
@ref{How do I determine how much memory is left?}.
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -1,135 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
|
||||
@node Date/Time Issues in Systems Using RTEMS, Hardware Issues, , Top
|
||||
|
||||
@chapter Date/Time Issues in Systems Using RTEMS
|
||||
@ifinfo
|
||||
@menu
|
||||
* Hardware Issues::
|
||||
* RTEMS Specific Issues::
|
||||
* Language Specific Issues::
|
||||
* Date/Time Conclusion::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
This section provides technical information regarding
|
||||
date/time representation issues and RTEMS. The Y2K problem has
|
||||
lead numerous people to ask these questions. The answer to
|
||||
these questions are actually more complicated than most
|
||||
people asking the question expect. RTEMS supports multiple
|
||||
standards and each of these standards has its own epoch and
|
||||
time representation. These standards include both programming
|
||||
API and programming language standards.
|
||||
|
||||
In addition to the issues inside RTEMS
|
||||
itself, there is the complicating factor that the Board
|
||||
Support Package or application itself may interface with hardware
|
||||
or software that has its own set of date/time representation
|
||||
issues.
|
||||
|
||||
In conclusion, viewing date/time representation as "the Y2K problem"
|
||||
is very short-sighted. Date/time representation should be viewed as
|
||||
a systems level issue for the system you are building. Each software
|
||||
and hardware component in the system as well as the systems being
|
||||
connected to is a factor in the equation.
|
||||
|
||||
|
||||
@node Hardware Issues, RTEMS Specific Issues, Date/Time Issues in Systems Using RTEMS, Date/Time Issues in Systems Using RTEMS
|
||||
|
||||
@section Hardware Issues
|
||||
|
||||
Numerous Real-Time Clock (RTC) controllers provide only a two-digit
|
||||
Binary Coded Decimal (BCD) representation for the current year. Without
|
||||
software correction, these chips are a classic example of the Y2K problem.
|
||||
When the RTC rolls the year register over from 99 to 00, the device
|
||||
has no idea whether the year is 1900 or 2000. It is the responsibility
|
||||
of the device driver to recognize this condition and correct for it.
|
||||
The most common technique used is to assume that all years prior
|
||||
to either the existence of the board or RTEMS are past 2000. The
|
||||
starting year (epoch) for RTEMS is 1988. Thus,
|
||||
|
||||
@itemize @bullet
|
||||
@item Chip year values 88-99 are interpreted as years 1988-2002.
|
||||
@item Chip year values 00-87 are interpreted as years 2000-2087.
|
||||
@end itemize
|
||||
|
||||
Using this technique, a RTC using a
|
||||
two-digit BCD representation of the current year will overflow on
|
||||
January 1, 2088.
|
||||
|
||||
|
||||
@node RTEMS Specific Issues, Language Specific Issues, Hardware Issues, Date/Time Issues in Systems Using RTEMS
|
||||
|
||||
@section RTEMS Specific Issues
|
||||
|
||||
Internally, RTEMS uses an unsigned thirty-two bit integer to represent the
|
||||
number of seconds since midnight January 1, 1988. This counter will
|
||||
overflow on February 5, 2124.
|
||||
|
||||
The time/date services in the Classic API will overflow when the
|
||||
RTEMS internal date/time representation overflows.
|
||||
|
||||
The POSIX API uses the type @i{time_t} to represent the number of
|
||||
seconds since January 1, 1970. Many traditional UNIX systems as
|
||||
well as RTEMS define @i{time_t} as a signed thirty-two bit integer.
|
||||
This representation overflows on January 18, 2038. The solution
|
||||
usually proposed is to define @i{time_t} as a sixty-four bit
|
||||
integer. This solution is appropriate for for UNIX workstations
|
||||
as many of them already support sixty-four bit integers natively.
|
||||
At this time, this imposes a burden on embedded systems which are
|
||||
still primarily using processors with native integers of thirty-two
|
||||
bits or less.
|
||||
|
||||
|
||||
@node Language Specific Issues, Date/Time Conclusion, RTEMS Specific Issues, Date/Time Issues in Systems Using RTEMS
|
||||
|
||||
@section Language Specific Issues
|
||||
|
||||
The Ada95 Language Reference Manual requires that the @i{Ada.Calendar}
|
||||
package support years through the year 2099. However, just as the
|
||||
hardware is layered on top of hardware and may inherit its limits,
|
||||
the Ada tasking and run-time support is layered on top of an operating
|
||||
system. Thus, if the operating system or underlying hardware fail
|
||||
to correctly report dates after 2099, then it is possible for the
|
||||
@i{Ada.Calendar} package to fail prior to 2099.
|
||||
|
||||
|
||||
@node Date/Time Conclusion, , Language Specific Issues, Date/Time Issues in Systems Using RTEMS
|
||||
|
||||
@section Date/Time Conclusion
|
||||
|
||||
Each embedded system could be impacted by a variety of date/time
|
||||
representation issues. Even whether a particular date/time
|
||||
representation issue impacts a system is questionable. A system
|
||||
using only the RTEMS Classic API is not impacted by the
|
||||
date/time representation issues in POSIX. A system not using
|
||||
date/time at all is not impacted by any of these issues. Also
|
||||
the planned end of life for a system may make these issues
|
||||
moot.
|
||||
|
||||
The following is a timeline of the date/time representation
|
||||
issues presented in this section:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item 2000 - Two BCD Digit Real-Time Clock Rollover
|
||||
|
||||
@item 2038 - POSIX @i{time_t} Rollover
|
||||
|
||||
@item 2088 - Correction for Two BCD Digit Real-Time Clock Rollover
|
||||
|
||||
@item 2099 - Ada95 @i{Ada.Calendar} Rollover
|
||||
|
||||
@item 2124 - RTEMS Internal Seconds Counter Rollover
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
|
||||
File diff suppressed because it is too large.
Load diff
@@ -1,126 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
|
||||
@node Hardware to Ease Debugging, MC683xx BDM Support for GDB, , Top
|
||||
|
||||
@chapter Hardware to Ease Debugging
|
||||
@ifinfo
|
||||
@menu
|
||||
* MC683xx BDM Support for GDB::
|
||||
* MPC8xx BDM Support for GDB::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
The items in this category provide information on various hardware
|
||||
debugging assistants that are available.
|
||||
|
||||
|
||||
@node MC683xx BDM Support for GDB, MPC8xx BDM Support for GDB, Hardware to Ease Debugging, Hardware to Ease Debugging
|
||||
|
||||
@section MC683xx BDM Support for GDB
|
||||
|
||||
Eric Norum (eric@@skatter.usask.ca) has a driver for a parallel
|
||||
port interface to a BDM module. This driver has a long history
|
||||
and is based on a driver by Gunter Magin (magin@@skil.camelot.de)
|
||||
which in turn was based on BD32 for DOS by Scott Howard. Eric Norum
|
||||
and Chris Johns (ccj@@acm.org) have put together a package containing
|
||||
everything you need to use this BDM driver including software, PCB layouts,
|
||||
and machining drawings. From the README:
|
||||
|
||||
"This package contains everything you need to be able to run GDB on
|
||||
Linux and control a Motorola CPU32+ (68360) or Coldfire (5206, 5206e, or
|
||||
5207) target through a standard PC parallel port."
|
||||
|
||||
Information on this BDM driver is available at the following URL:
|
||||
|
||||
@example
|
||||
http://www.calm.hw.ac.uk/davidf/coldfire/gdb-bdm-linux.htm
|
||||
@end example
|
||||
|
||||
The package is officially hosted at Eric Norum's ftp site:
|
||||
|
||||
@example
|
||||
ftp://skatter.usask.ca/pub/eric/BDM-Linux-gdb/
|
||||
@end example
|
||||
|
||||
Peter Shoebridge (peter@@zeecube.com) has ported the Linux
|
||||
parallel port BDM driver from Eric Norum to Windows NT. It is
|
||||
available at http://www.zeecube.com/bdm.
|
||||
|
||||
The efi332 project has a home-built BDM module and gdb backend for
|
||||
Linux. See http://efi332.eng.ohio-state.edu/efi332/hardware.html)
|
||||
for details. The device driver and gdb backend are based on those
|
||||
by Gunter Magin (magin@@skil.camelot.de) available from
|
||||
ftp.lpr.e-technik.tu-muenchen.de.
|
||||
|
||||
Pavel Pisa (pisa@@cmp.felk.cvut.cz) has one available at
|
||||
http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html.
|
||||
|
||||
Huntsville Microsystems (HMI) has GDB support for their BDM module
|
||||
available upon request. It is also available from their ftp site:
|
||||
ftp://ftp.hmi.com/pub/gdb
|
||||
|
||||
The Macraigor OCD BDM module has a driver for Linux
|
||||
written by Gunter Magin (magin@@skil.camelot.de).
|
||||
No URLs yet.
|
||||
|
||||
Finally, there is a overview of BDM at the following URL:
|
||||
http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html.
|
||||
|
||||
Information in this section from:
|
||||
|
||||
@itemize @bullet
|
||||
@item Brendan Simon <brendan@@dgs.monash.edu.au>
|
||||
@item W Gerald Hicks <wghicks@@bellsouth.net>
|
||||
@item Chris Johns <ccj@@acm.org>
|
||||
@item Eric Norum <eric@@skatter.usask.ca>
|
||||
@item Gunter Magin <magin@@skil.camelot.de>
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
|
||||
@node MPC8xx BDM Support for GDB, , MC683xx BDM Support for GDB, Hardware to Ease Debugging
|
||||
|
||||
@section MPC8xx BDM Support for GDB
|
||||
|
||||
@c "Adrian Bocaniciu" <a.bocaniciu@computer.org> has a driver
|
||||
@c for NT and is willing to share it but he needs to be emailed
|
||||
@c privately since he needs to explain somethings about it.
|
||||
@c It has been used for over a year as of 08/18/99.
|
||||
|
||||
Christian Haan <chn@@intego.de> has written a driver for FreeBSD
|
||||
based for"a slightly changed ICD BDM module (because of changes
|
||||
in the BDM interface on the PowerPC)" that "probably will work with
|
||||
the PD module too." His work is based on the M68K BDM work by
|
||||
Gunter Magin (Gunter.Magin@@skil.camelot.de) and
|
||||
the PPC BDM for Linux work by Sergey Drazhnikov (swd@@agua.comptek.ru).
|
||||
This is not yet publicly available.
|
||||
|
||||
Sergey Drazhnikov (swd@@agua.comptek.ru) has written a PPC BDM driver for
|
||||
Linux. Information is available at http://cyclone.parad.ru/ppcbdm.
|
||||
|
||||
Huntsville Microsystems (HMI) has GDB support for their BDM module
|
||||
available upon request. It is also available from their ftp site:
|
||||
ftp://ftp.hmi.com/pub/gdb
|
||||
|
||||
GDB includes support for a set of primitives to support the Macraigor
|
||||
Wiggler (OCD BDM). Unfortunately, this requires the use of a
|
||||
proprietary interface and is supported only on Windows. This forces
|
||||
one to use CYGWIN. Reports are that this results in a slow
|
||||
interface. Scott Howard (http://www.objsw.com) has announced
|
||||
that support for the gdb+wiggler combination under DJGPP which should
|
||||
run significantly faster.
|
||||
|
||||
@itemize @bullet
|
||||
@item Leon Pollak <leonp@@plris.com>
|
||||
@item Christian Haan <chn@@intego.de>
|
||||
@end itemize
|
||||
|
||||
|
||||
@@ -1,169 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
|
||||
@node RTEMS Projects, Other Filesystems, , Top
|
||||
|
||||
@chapter RTEMS Projects
|
||||
@ifinfo
|
||||
@menu
|
||||
* Other Filesystems::
|
||||
* Java::
|
||||
* CORBA::
|
||||
* APIs::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
The questions in this category are regarding things that people
|
||||
are working on or that the RTEMS community would like to see work on.
|
||||
|
||||
There are multiple ways to support the RTEMS Project. Financial support
|
||||
is always welcomed. This can be via sponsorship of a specific project
|
||||
such as one of the ones listed here or via volunteering in some
|
||||
capacity.
|
||||
|
||||
|
||||
@node Other Filesystems, Java, RTEMS Projects, RTEMS Projects
|
||||
|
||||
@section Other Filesystems
|
||||
|
||||
This is a list of the filesystems that would be nice to have support
|
||||
for in RTEMS. For each filsystem, status and contact information is
|
||||
provided for those who have expressed interest in helping out or are actively
|
||||
working on it.
|
||||
|
||||
@itemize @bullet
|
||||
@item TFTP client - read only, no write capability
|
||||
@itemize @bullet
|
||||
@item No Contact
|
||||
@end itemize
|
||||
|
||||
@item DOS Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Peter Shoebridge <peter@@zeecube.com>
|
||||
@item Victor V. Vengerov <vvv@@tepkom.ru>
|
||||
@end itemize
|
||||
|
||||
@item CD-ROM Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Peter Shoebridge <peter@@zeecube.com>
|
||||
@end itemize
|
||||
|
||||
@item Flash Filesystem(s) - ???
|
||||
@itemize @bullet
|
||||
@item Rod Barman <rodb@@ieee.org>
|
||||
@item Victor V. Vengerov <vvv@@tepkom.ru>
|
||||
@end itemize
|
||||
|
||||
@item Remote Host Filesystem - ???
|
||||
@itemize @bullet
|
||||
@item Wayne Bullaughey <wayne@@wmi.com>
|
||||
@end itemize
|
||||
|
||||
@item NFS client - ???
|
||||
@itemize @bullet
|
||||
@item No Contact
|
||||
@end itemize
|
||||
|
||||
@end itemize
|
||||
|
||||
|
||||
@node Java, Kaffe, Other Filesystems, RTEMS Projects
|
||||
|
||||
@section Java
|
||||
@ifinfo
|
||||
@menu
|
||||
* Kaffe::
|
||||
* GNU Java Compiler (gjc)::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
|
||||
@node Kaffe, GNU Java Compiler (gjc), Java, Java
|
||||
|
||||
@subsection Kaffe
|
||||
|
||||
This porting effort is underway and active.
|
||||
|
||||
@itemize @bullet
|
||||
@item Jiri Gaisler <jgais@@ws.estec.esa.nl>
|
||||
@item Oscar Martinez de la Torre <omt@@wm.estec.esa.nl>
|
||||
@end itemize
|
||||
|
||||
NOTE: An older version of Kaffe was ported to a pre-4.0 version of RTEMS.
|
||||
The network support in RTEMS was immature at that port and Kaffe had
|
||||
portability problems. Together these resulted in an unclean port which
|
||||
was never merged.
|
||||
|
||||
|
||||
@node GNU Java Compiler (gjc), CORBA, Kaffe, Java
|
||||
|
||||
@subsection GNU Java Compiler (gjc)
|
||||
|
||||
This porting effort is underway and active.
|
||||
|
||||
@itemize @bullet
|
||||
@item Charles-Antoine Gauthier <charles.gauthier@@iit.nrc.ca>
|
||||
@end itemize
|
||||
|
||||
|
||||
@node CORBA, TAO, GNU Java Compiler (gjc), RTEMS Projects
|
||||
|
||||
@section CORBA
|
||||
@ifinfo
|
||||
@menu
|
||||
* TAO::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
|
||||
@node TAO, APIs, CORBA, CORBA
|
||||
|
||||
@subsection TAO
|
||||
|
||||
This porting effort is pending testing. Erik ported the code but then
|
||||
discovered that his target board did not have enough memory to run
|
||||
any TAO tests.
|
||||
|
||||
@itemize @bullet
|
||||
@item Erik Ivanenko <erik.ivanenko@@utoronto.ca>
|
||||
@end itemize
|
||||
|
||||
|
||||
@node APIs, POSIX 1003.1b, TAO, RTEMS Projects
|
||||
|
||||
@section APIs
|
||||
@ifinfo
|
||||
@menu
|
||||
* POSIX 1003.1b::
|
||||
* ITRON 3.0::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
|
||||
@node POSIX 1003.1b, ITRON 3.0, APIs, APIs
|
||||
|
||||
@subsection POSIX 1003.1b
|
||||
|
||||
Support for POSIX 1003.1b is mature but there are a few remaining
|
||||
items including a handful of services, performance tests, and
|
||||
documentation. Please refer to the Status chapter of the
|
||||
@i{POSIX API User's Guide} for more details.
|
||||
|
||||
|
||||
@node ITRON 3.0, , POSIX 1003.1b, APIs
|
||||
|
||||
@subsection ITRON 3.0
|
||||
|
||||
Support for ITRON 3.0 is in its beginning stages. There are
|
||||
numerous managers left to implement, both functional and
|
||||
performance tests to write, and much documentation remaining.
|
||||
Please refer to the Status chapter of the @i{ITRON 3.0 API User's Guide}
|
||||
for specific details.
|
||||
|
||||
|
||||
@@ -1,91 +0,0 @@
|
||||
@c
|
||||
@c COPYRIGHT (c) 1988-2002.
|
||||
@c On-Line Applications Research Corporation (OAR).
|
||||
@c All rights reserved.
|
||||
@c
|
||||
@c $Id$
|
||||
@c
|
||||
|
||||
|
||||
@node General Development Tool Hints, What is GNU?, Top, Top
|
||||
|
||||
@chapter General Development Tool Hints
|
||||
@ifinfo
|
||||
@menu
|
||||
* What is GNU?::
|
||||
* How do I generate a patch?::
|
||||
* How do I apply a patch?::
|
||||
@end menu
|
||||
@end ifinfo
|
||||
|
||||
The questions in this category are related to the GNU development tools
|
||||
in a non-language specific way.
|
||||
|
||||
|
||||
@node What is GNU?, How do I generate a patch?, General Development Tool Hints, General Development Tool Hints
|
||||
|
||||
@section What is GNU?
|
||||
|
||||
Take a look at @uref{http://www.gnu.org,http://www.gnu.org} for information on the GNU Project.
|
||||
|
||||
|
||||
@node How do I generate a patch?, How do I apply a patch?, What is GNU?, General Development Tool Hints
|
||||
|
||||
@section How do I generate a patch?
|
||||
|
||||
The RTEMS patches to the development tools are generated using a
|
||||
command like this
|
||||
|
||||
@example
|
||||
diff -N -P -r -c TOOL-original-image TOOL-with-changes >PATCHFILE
|
||||
@end example
|
||||
|
||||
where the options are:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item -N and -P take care of adding and removing files (be careful not to
|
||||
include junk files like file.mybackup)
|
||||
|
||||
@item -r tells diff to recurse through subdirectories
|
||||
|
||||
@item -c is a context diff (easy to read for humans)
|
||||
|
||||
@end itemize
|
||||
|
||||
Please look at the generated PATCHFILE and make sure it does not
|
||||
contain anything you did not intend to send to the maintainers.
|
||||
It is easy to accidentally leave a backup file in the modified
|
||||
source tree or have a spurious change that should not be
|
||||
in the PATCHFILE.
|
||||
|
||||
If you end up with the entire contents of a file in the patch
|
||||
and can't figure out why, you may have different CR/LF scheme
|
||||
in the two source files. The GNU open-source packages usually have
|
||||
UNIX style CR/LF. If you edit on a Windows platform, the line
|
||||
terminators may have been transformed by the editor into Windows
|
||||
style.
|
||||
|
||||
|
||||
@node How do I apply a patch?, , How do I generate a patch?, General Development Tool Hints
|
||||
|
||||
@section How do I apply a patch?
|
||||
|
||||
Patches generated with the @code{diff} program are fed into the
|
||||
@code{patch} program as follows:
|
||||
|
||||
@example
|
||||
patch -p1 <PATCHFILE
|
||||
@end example
|
||||
|
||||
where the options are:
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item -pNUM tells @code{patch} to strip off NUM slashes from the
|
||||
pathname.
|
||||
|
||||
@end itemize
|
||||
|
||||
If @code{patch} prompts for a file to patch, you may need to adjust NUM.
|
||||
|
||||
Reference in new issue
Block a user