Browse Source
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!master v2.6.12-rc2
Linus Torvalds
18 years ago
commit
1da177e4c3
17291 changed files with 6718755 additions and 0 deletions
@ -0,0 +1,294 @@
|
||||
|
||||
This is a brief list of all the files in ./linux/Documentation and what |
||||
they contain. If you add a documentation file, please list it here in |
||||
alphabetical order as well, or risk being hunted down like a rabid dog. |
||||
Please try and keep the descriptions small enough to fit on one line. |
||||
Thanks -- Paul G. |
||||
|
||||
Following translations are available on the WWW: |
||||
|
||||
- Japanese, maintained by the JF Project (JF@linux.or.jp), at |
||||
http://www.linux.or.jp/JF/ |
||||
|
||||
00-INDEX |
||||
- this file. |
||||
BK-usage/ |
||||
- directory with info on BitKeeper. |
||||
BUG-HUNTING |
||||
- brute force method of doing binary search of patches to find bug. |
||||
Changes |
||||
- list of changes that break older software packages. |
||||
CodingStyle |
||||
- how the boss likes the C code in the kernel to look. |
||||
DMA-API.txt |
||||
- DMA API, pci_ API & extensions for non-consistent memory machines. |
||||
DMA-mapping.txt |
||||
- info for PCI drivers using DMA portably across all platforms. |
||||
DocBook/ |
||||
- directory with DocBook templates etc. for kernel documentation. |
||||
IO-mapping.txt |
||||
- how to access I/O mapped memory from within device drivers. |
||||
IPMI.txt |
||||
- info on Linux Intelligent Platform Management Interface (IPMI) Driver. |
||||
IRQ-affinity.txt |
||||
- how to select which CPU(s) handle which interrupt events on SMP. |
||||
ManagementStyle |
||||
- how to (attempt to) manage kernel hackers. |
||||
MSI-HOWTO.txt |
||||
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ. |
||||
RCU/ |
||||
- directory with info on RCU (read-copy update). |
||||
README.DAC960 |
||||
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux. |
||||
SAK.txt |
||||
- info on Secure Attention Keys. |
||||
SubmittingDrivers |
||||
- procedure to get a new driver source included into the kernel tree. |
||||
SubmittingPatches |
||||
- procedure to get a source patch included into the kernel tree. |
||||
VGA-softcursor.txt |
||||
- how to change your VGA cursor from a blinking underscore. |
||||
arm/ |
||||
- directory with info about Linux on the ARM architecture. |
||||
basic_profiling.txt |
||||
- basic instructions for those who wants to profile Linux kernel. |
||||
binfmt_misc.txt |
||||
- info on the kernel support for extra binary formats. |
||||
block/ |
||||
- info on the Block I/O (BIO) layer. |
||||
cachetlb.txt |
||||
- describes the cache/TLB flushing interfaces Linux uses. |
||||
cciss.txt |
||||
- info, major/minor #'s for Compaq's SMART Array Controllers. |
||||
cdrom/ |
||||
- directory with information on the CD-ROM drivers that Linux has. |
||||
cli-sti-removal.txt |
||||
- cli()/sti() removal guide. |
||||
computone.txt |
||||
- info on Computone Intelliport II/Plus Multiport Serial Driver. |
||||
cpqarray.txt |
||||
- info on using Compaq's SMART2 Intelligent Disk Array Controllers. |
||||
cpu-freq/ |
||||
- info on CPU frequency and voltage scaling. |
||||
cris/ |
||||
- directory with info about Linux on CRIS architecture. |
||||
crypto/ |
||||
- directory with info on the Crypto API. |
||||
debugging-modules.txt |
||||
- some notes on debugging modules after Linux 2.6.3. |
||||
device-mapper/ |
||||
- directory with info on Device Mapper. |
||||
devices.txt |
||||
- plain ASCII listing of all the nodes in /dev/ with major minor #'s. |
||||
digiepca.txt |
||||
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards. |
||||
dnotify.txt |
||||
- info about directory notification in Linux. |
||||
driver-model/ |
||||
- directory with info about Linux driver model. |
||||
dvb/ |
||||
- info on Linux Digital Video Broadcast (DVB) subsystem. |
||||
early-userspace/ |
||||
- info about initramfs, klibc, and userspace early during boot. |
||||
eisa.txt |
||||
- info on EISA bus support. |
||||
exception.txt |
||||
- how Linux v2.2 handles exceptions without verify_area etc. |
||||
fb/ |
||||
- directory with info on the frame buffer graphics abstraction layer. |
||||
filesystems/ |
||||
- directory with info on the various filesystems that Linux supports. |
||||
firmware_class/ |
||||
- request_firmware() hotplug interface info. |
||||
floppy.txt |
||||
- notes and driver options for the floppy disk driver. |
||||
ftape.txt |
||||
- notes about the floppy tape device driver. |
||||
hayes-esp.txt |
||||
- info on using the Hayes ESP serial driver. |
||||
highuid.txt |
||||
- notes on the change from 16 bit to 32 bit user/group IDs. |
||||
hpet.txt |
||||
- High Precision Event Timer Driver for Linux. |
||||
hw_random.txt |
||||
- info on Linux support for random number generator in i8xx chipsets. |
||||
i2c/ |
||||
- directory with info about the I2C bus/protocol (2 wire, kHz speed). |
||||
i2o/ |
||||
- directory with info about the Linux I2O subsystem. |
||||
i386/ |
||||
- directory with info about Linux on Intel 32 bit architecture. |
||||
ia64/ |
||||
- directory with info about Linux on Intel 64 bit architecture. |
||||
ide.txt |
||||
- important info for users of ATA devices (IDE/EIDE disks and CD-ROMS). |
||||
initrd.txt |
||||
- how to use the RAM disk as an initial/temporary root filesystem. |
||||
input/ |
||||
- info on Linux input device support. |
||||
io_ordering.txt |
||||
- info on ordering I/O writes to memory-mapped addresses. |
||||
ioctl-number.txt |
||||
- how to implement and register device/driver ioctl calls. |
||||
iostats.txt |
||||
- info on I/O statistics Linux kernel provides. |
||||
isapnp.txt |
||||
- info on Linux ISA Plug & Play support. |
||||
isdn/ |
||||
- directory with info on the Linux ISDN support, and supported cards. |
||||
java.txt |
||||
- info on the in-kernel binary support for Java(tm). |
||||
kbuild/ |
||||
- directory with info about the kernel build process. |
||||
kernel-doc-nano-HOWTO.txt |
||||
- mini HowTo on generation and location of kernel documentation files. |
||||
kernel-docs.txt |
||||
- listing of various WWW + books that document kernel internals. |
||||
kernel-parameters.txt |
||||
- summary listing of command line / boot prompt args for the kernel. |
||||
kobject.txt |
||||
- info of the kobject infrastructure of the Linux kernel. |
||||
laptop-mode.txt |
||||
- How to conserve battery power using laptop-mode. |
||||
ldm.txt |
||||
- a brief description of LDM (Windows Dynamic Disks). |
||||
locks.txt |
||||
- info on file locking implementations, flock() vs. fcntl(), etc. |
||||
logo.gif |
||||
- Full colour GIF image of Linux logo (penguin). |
||||
logo.txt |
||||
- Info on creator of above logo & site to get additional images from. |
||||
m68k/ |
||||
- directory with info about Linux on Motorola 68k architecture. |
||||
magic-number.txt |
||||
- list of magic numbers used to mark/protect kernel data structures. |
||||
mandatory.txt |
||||
- info on the Linux implementation of Sys V mandatory file locking. |
||||
mca.txt |
||||
- info on supporting Micro Channel Architecture (e.g. PS/2) systems. |
||||
md.txt |
||||
- info on boot arguments for the multiple devices driver. |
||||
memory.txt |
||||
- info on typical Linux memory problems. |
||||
mips/ |
||||
- directory with info about Linux on MIPS architecture. |
||||
mono.txt |
||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC. |
||||
moxa-smartio |
||||
- info on installing/using Moxa multiport serial driver. |
||||
mtrr.txt |
||||
- how to use PPro Memory Type Range Registers to increase performance. |
||||
nbd.txt |
||||
- info on a TCP implementation of a network block device. |
||||
networking/ |
||||
- directory with info on various aspects of networking with Linux. |
||||
nfsroot.txt |
||||
- short guide on setting up a diskless box with NFS root filesystem. |
||||
nmi_watchdog.txt |
||||
- info on NMI watchdog for SMP systems. |
||||
numastat.txt |
||||
- info on how to read Numa policy hit/miss statistics in sysfs. |
||||
oops-tracing.txt |
||||
- how to decode those nasty internal kernel error dump messages. |
||||
paride.txt |
||||
- information about the parallel port IDE subsystem. |
||||
parisc/ |
||||
- directory with info on using Linux on PA-RISC architecture. |
||||
parport.txt |
||||
- how to use the parallel-port driver. |
||||
parport-lowlevel.txt |
||||
- description and usage of the low level parallel port functions. |
||||
pci.txt |
||||
- info on the PCI subsystem for device driver authors. |
||||
pm.txt |
||||
- info on Linux power management support. |
||||
pnp.txt |
||||
- Linux Plug and Play documentation. |
||||
power/ |
||||
- directory with info on Linux PCI power management. |
||||
powerpc/ |
||||
- directory with info on using Linux with the PowerPC. |
||||
preempt-locking.txt |
||||
- info on locking under a preemptive kernel. |
||||
ramdisk.txt |
||||
- short guide on how to set up and use the RAM disk. |
||||
riscom8.txt |
||||
- notes on using the RISCom/8 multi-port serial driver. |
||||
rocket.txt |
||||
- info on the Comtrol RocketPort multiport serial driver. |
||||
rpc-cache.txt |
||||
- introduction to the caching mechanisms in the sunrpc layer. |
||||
rtc.txt |
||||
- notes on how to use the Real Time Clock (aka CMOS clock) driver. |
||||
s390/ |
||||
- directory with info on using Linux on the IBM S390. |
||||
sched-coding.txt |
||||
- reference for various scheduler-related methods in the O(1) scheduler. |
||||
sched-design.txt |
||||
- goals, design and implementation of the Linux O(1) scheduler. |
||||
sched-domains.txt |
||||
- information on scheduling domains. |
||||
sched-stats.txt |
||||
- information on schedstats (Linux Scheduler Statistics). |
||||
scsi/ |
||||
- directory with info on Linux scsi support. |
||||
serial/ |
||||
- directory with info on the low level serial API. |
||||
serial-console.txt |
||||
- how to set up Linux with a serial line console as the default. |
||||
sgi-visws.txt |
||||
- short blurb on the SGI Visual Workstations. |
||||
sh/ |
||||
- directory with info on porting Linux to a new architecture. |
||||
smart-config.txt |
||||
- description of the Smart Config makefile feature. |
||||
smp.txt |
||||
- a few notes on symmetric multi-processing. |
||||
sonypi.txt |
||||
- info on Linux Sony Programmable I/O Device support. |
||||
sound/ |
||||
- directory with info on sound card support. |
||||
sparc/ |
||||
- directory with info on using Linux on Sparc architecture. |
||||
specialix.txt |
||||
- info on hardware/driver for specialix IO8+ multiport serial card. |
||||
spinlocks.txt |
||||
- info on using spinlocks to provide exclusive access in kernel. |
||||
stallion.txt |
||||
- info on using the Stallion multiport serial driver. |
||||
svga.txt |
||||
- short guide on selecting video modes at boot via VGA BIOS. |
||||
sx.txt |
||||
- info on the Specialix SX/SI multiport serial driver. |
||||
sysctl/ |
||||
- directory with info on the /proc/sys/* files. |
||||
sysrq.txt |
||||
- info on the magic SysRq key. |
||||
telephony/ |
||||
- directory with info on telephony (e.g. voice over IP) support. |
||||
time_interpolators.txt |
||||
- info on time interpolators. |
||||
tipar.txt |
||||
- information about Parallel link cable for Texas Instruments handhelds. |
||||
tty.txt |
||||
- guide to the locking policies of the tty layer. |
||||
unicode.txt |
||||
- info on the Unicode character/font mapping used in Linux. |
||||
uml/ |
||||
- directory with infomation about User Mode Linux. |
||||
usb/ |
||||
- directory with info regarding the Universal Serial Bus. |
||||
video4linux/ |
||||
- directory with info regarding video/TV/radio cards and linux. |
||||
vm/ |
||||
- directory with info on the Linux vm code. |
||||
voyager.txt |
||||
- guide to running Linux on the Voyager architecture. |
||||
watchdog/ |
||||
- how to auto-reboot Linux if it has "fallen and can't get up". ;-) |
||||
x86_64/ |
||||
- directory with info on Linux support for AMD x86-64 (Hammer) machines. |
||||
xterm-linux.xpm |
||||
- XPM image of penguin logo (see logo.txt) sitting on an xterm. |
||||
zorro.txt |
||||
- info on writing drivers for Zorro bus devices found on Amigas. |
||||
@ -0,0 +1,51 @@
|
||||
bk-kernel-howto.txt: Description of kernel workflow under BitKeeper |
||||
|
||||
bk-make-sum: Create summary of changesets in one repository and not |
||||
another, typically in preparation to be sent to an upstream maintainer. |
||||
Typical usage: |
||||
cd my-updated-repo |
||||
bk-make-sum ~/repo/original-repo |
||||
mv /tmp/linus.txt ../original-repo.txt |
||||
|
||||
bksend: Create readable text output containing summary of changes, GNU |
||||
patch of the changes, and BK metadata of changes (as needed for proper |
||||
importing into BitKeeper by an upstream maintainer). This output is |
||||
suitable for emailing BitKeeper changes. The recipient of this output |
||||
may pipe it directly to 'bk receive'. |
||||
|
||||
bz64wrap: helper script. Uncompressed input is piped to this script, |
||||
which compresses its input, and then outputs the uu-/base64-encoded |
||||
version of the compressed input. |
||||
|
||||
cpcset: Copy changeset between unrelated repositories. |
||||
Attempts to preserve changeset user, user address, description, in |
||||
addition to the changeset (the patch) itself. |
||||
Typical usage: |
||||
cd my-updated-repo |
||||
bk changes # looking for a changeset... |
||||
cpcset 1.1511 . ../another-repo |
||||
|
||||
csets-to-patches: Produces a delta of two BK repositories, in the form |
||||
of individual files, each containing a single cset as a GNU patch. |
||||
Output is several files, each with the filename "/tmp/rev-$REV.patch" |
||||
Typical usage: |
||||
cd my-updated-repo |
||||
bk changes -L ~/repo/original-repo 2>&1 | \ |
||||
perl csets-to-patches |
||||
|
||||
cset-to-linus: Produces a delta of two BK repositories, in the form of |
||||
changeset descriptions, with 'diffstat' output created for each |
||||
individual changset. |
||||
Typical usage: |
||||
cd my-updated-repo |
||||
bk changes -L ~/repo/original-repo 2>&1 | \ |
||||
perl cset-to-linus > summary.txt |
||||
|
||||
gcapatch: Generates patch containing changes in local repository. |
||||
Typical usage: |
||||
cd my-updated-repo |
||||
gcapatch > foo.patch |
||||
|
||||
unbz64wrap: Reverse an encoded, compressed data stream created by |
||||
bz64wrap into an uncompressed, typically text/plain output. |
||||
|
||||
@ -0,0 +1,283 @@
|
||||
|
||||
Doing the BK Thing, Penguin-Style |
||||
|
||||
|
||||
|
||||
|
||||
This set of notes is intended mainly for kernel developers, occasional |
||||
or full-time, but sysadmins and power users may find parts of it useful |
||||
as well. It assumes at least a basic familiarity with CVS, both at a |
||||
user level (use on the cmd line) and at a higher level (client-server model). |
||||
Due to the author's background, an operation may be described in terms |
||||
of CVS, or in terms of how that operation differs from CVS. |
||||
|
||||
This is -not- intended to be BitKeeper documentation. Always run |
||||
"bk help <command>" or in X "bk helptool <command>" for reference |
||||
documentation. |
||||
|
||||
|
||||
BitKeeper Concepts |
||||
------------------ |
||||
|
||||
In the true nature of the Internet itself, BitKeeper is a distributed |
||||
system. When applied to revision control, this means doing away with |
||||
client-server, and changing to a parent-child model... essentially |
||||
peer-to-peer. On the developer's end, this also represents a |
||||
fundamental disruption in the standard workflow of changes, commits, |
||||
and merges. You will need to take a few minutes to think about |
||||
how to best work under BitKeeper, and re-optimize things a bit. |
||||
In some sense it is a bit radical, because it might described as |
||||
tossing changes out into a maelstrom and having them magically |
||||
land at the right destination... but I'm getting ahead of myself. |
||||
|
||||
Let's start with this progression: |
||||
Each BitKeeper source tree on disk is a repository unto itself. |
||||
Each repository has a parent (except the root/original, of course). |
||||
Each repository contains a set of a changesets ("csets"). |
||||
Each cset is one or more changed files, bundled together. |
||||
|
||||
Each tree is a repository, so all changes are checked into the local |
||||
tree. When a change is checked in, all modified files are grouped |
||||
into a logical unit, the changeset. Internally, BK links these |
||||
changesets in a tree, representing various converging and diverging |
||||
lines of development. These changesets are the bread and butter of |
||||
the BK system. |
||||
|
||||
After the concept of changesets, the next thing you need to get used |
||||
to is having multiple copies of source trees lying around. This -really- |
||||
takes some getting used to, for some people. Separate source trees |
||||
are the means in BitKeeper by which you delineate parallel lines |
||||
of development, both minor and major. What would be branches in |
||||
CVS become separate source trees, or "clones" in BitKeeper [heh, |
||||
or Star Wars] terminology. |
||||
|
||||
Clones and changesets are the tools from which most of the power of |
||||
BitKeeper is derived. As mentioned earlier, each clone has a parent, |
||||
the tree used as the source when the new clone was created. In a |
||||
CVS-like setup, the parent would be a remote server on the Internet, |
||||
and the child is your local clone of that tree. |
||||
|
||||
Once you have established a common baseline between two source trees -- |
||||
a common parent -- then you can merge changesets between those two |
||||
trees with ease. Merging changes into a tree is called a "pull", and |
||||
is analagous to 'cvs update'. A pull downloads all the changesets in |
||||
the remote tree you do not have, and merges them. Sending changes in |
||||
one tree to another tree is called a "push". Push sends all changes |
||||
in the local tree the remote does not yet have, and merges them. |
||||
|
||||
From these concepts come some initial command examples: |
||||
|
||||
1) bk clone -q http://linux.bkbits.net/linux-2.5 linus-2.5 |
||||
Download a 2.5 stock kernel tree, naming it "linus-2.5" in the local dir. |
||||
The "-q" disables listing every single file as it is downloaded. |
||||
|
||||
2) bk clone -ql linus-2.5 alpha-2.5 |
||||
Create a separate source tree for the Alpha AXP architecture. |
||||
The "-l" uses hard links instead of copying data, since both trees are |
||||
on the local disk. You can also replace the above with "bk lclone -q ..." |
||||
|
||||
You only clone a tree -once-. After cloning the tree lives a long time |
||||
on disk, being updating by pushes and pulls. |
||||
|
||||
3) cd alpha-2.5 ; bk pull http://gkernel.bkbits.net/alpha-2.5 |
||||
Download changes in "alpha-2.5" repository which are not present |
||||
in the local repository, and merge them into the source tree. |
||||
|
||||
4) bk -r co -q |
||||
Because every tree is a repository, files must be checked out before |
||||
they will be in their standard places in the source tree. |
||||
|
||||
5) bk vi fs/inode.c # example change... |
||||
bk citool # checkin, using X tool |
||||
bk push bk://gkernel@bkbits.net/alpha-2.5 # upload change |
||||
Typical example of a BK sequence that would replace the analagous CVS |
||||
situation, |
||||
vi fs/inode.c |
||||
cvs commit |
||||
|
||||
As this is just supposed to be a quick BK intro, for more in-depth |
||||
tutorials, live working demos, and docs, see http://www.bitkeeper.com/ |
||||
|
||||
|
||||
|
||||
BK and Kernel Development Workflow |
||||
---------------------------------- |
||||
Currently the latest 2.5 tree is available via "bk clone $URL" |
||||
and "bk pull $URL" at http://linux.bkbits.net/linux-2.5 |
||||
This should change in a few weeks to a kernel.org URL. |
||||
|
||||
|
||||
A big part of using BitKeeper is organizing the various trees you have |
||||
on your local disk, and organizing the flow of changes among those |
||||
trees, and remote trees. If one were to graph the relationships between |
||||
a desired BK setup, you are likely to see a few-many-few graph, like |
||||
this: |
||||
|
||||
linux-2.5 |
||||
| |
||||
merge-to-linus-2.5 |
||||
/ | | |
||||
/ | | |
||||
vm-hacks bugfixes filesys personal-hacks |
||||
\ | | / |
||||
\ | | / |
||||
\ | | / |
||||
testing-and-validation |
||||
|
||||
Since a "bk push" sends all changes not in the target tree, and |
||||
since a "bk pull" receives all changes not in the source tree, you want |
||||
to make sure you are only pushing specific changes to the desired tree, |
||||
not all changes from "peer parent" trees. For example, pushing a change |
||||
from the testing-and-validation tree would probably be a bad idea, |
||||
because it will push all changes from vm-hacks, bugfixes, filesys, and |
||||
personal-hacks trees into the target tree. |
||||
|
||||
One would typically work on only one "theme" at a time, either |
||||
vm-hacks or bugfixes or filesys, keeping those changes isolated in |
||||
their own tree during development, and only merge the isolated with |
||||
other changes when going upstream (to Linus or other maintainers) or |
||||
downstream (to your "union" trees, like testing-and-validation above). |
||||
|
||||
It should be noted that some of this separation is not just recommended |
||||
practice, it's actually [for now] -enforced- by BitKeeper. BitKeeper |
||||
requires that changesets maintain a certain order, which is the reason |
||||
that "bk push" sends all local changesets the remote doesn't have. This |
||||
separation may look like a lot of wasted disk space at first, but it |
||||
helps when two unrelated changes may "pollute" the same area of code, or |
||||
don't follow the same pace of development, or any other of the standard |
||||
reasons why one creates a development branch. |
||||
|
||||
Small development branches (clones) will appear and disappear: |
||||
|
||||
-------- A --------- B --------- C --------- D ------- |
||||
\ / |
||||
-----short-term devel branch----- |
||||
|
||||
While long-term branches will parallel a tree (or trees), with period |
||||
merge points. In this first example, we pull from a tree (pulls, |
||||
"\") periodically, such as what occurs when tracking changes in a |
||||
vendor tree, never pushing changes back up the line: |
||||
|
||||
-------- A --------- B --------- C --------- D ------- |
||||
\ \ \ |
||||
----long-term devel branch----------------- |
||||
|
||||
And then a more common case in Linux kernel development, a long term |
||||
branch with periodic merges back into the tree (pushes, "/"): |
||||
|
||||
-------- A --------- B --------- C --------- D ------- |
||||
\ \ / \ |
||||
----long-term devel branch----------------- |
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Submitting Changes to Linus |
||||
--------------------------- |
||||
There's a bit of an art, or style, of submitting changes to Linus. |
||||
Since Linus's tree is now (you might say) fully integrated into the |
||||
distributed BitKeeper system, there are several prerequisites to |
||||
properly submitting a BitKeeper change. All these prereq's are just |
||||
general cleanliness of BK usage, so as people become experts at BK, feel |
||||
free to optimize this process further (assuming Linus agrees, of |
||||
course). |
||||
|
||||
|
||||
|
||||
0) Make sure your tree was originally cloned from the linux-2.5 tree |
||||
created by Linus. If your tree does not have this as its ancestor, it |
||||
is impossible to reliably exchange changesets. |
||||
|
||||
|
||||
|
||||
1) Pay attention to your commit text. The commit message that |
||||
accompanies each changeset you submit will live on forever in history, |
||||
and is used by Linus to accurately summarize the changes in each |
||||
pre-patch. Remember that there is no context, so |
||||
"fix for new scheduler changes" |
||||
would be too vague, but |
||||
"fix mips64 arch for new scheduler switch_to(), TIF_xxx semantics" |
||||
would be much better. |
||||
|
||||
You can and should use the command "bk comment -C<rev>" to update the |
||||
commit text, and improve it after the fact. This is very useful for |
||||
development: poor, quick descriptions during development, which get |
||||
cleaned up using "bk comment" before issuing the "bk push" to submit the |
||||
changes. |
||||
|
||||
|
||||
|
||||
2) Include an Internet-available URL for Linus to pull from, such as |
||||
|
||||
Pull from: http://gkernel.bkbits.net/net-drivers-2.5 |
||||
|
||||
|
||||
|
||||
3) Include a summary and "diffstat -p1" of each changeset that will be |
||||
downloaded, when Linus issues a "bk pull". The author auto-generates |
||||
these summaries using "bk changes -L <parent>", to obtain a listing |
||||
of all the pending-to-send changesets, and their commit messages. |
||||
|
||||
It is important to show Linus what he will be downloading when he issues |
||||
a "bk pull", to reduce the time required to sift the changes once they |
||||
are downloaded to Linus's local machine. |
||||
|
||||
IMPORTANT NOTE: One of the features of BK is that your repository does |
||||
not have to be up to date, in order for Linus to receive your changes. |
||||
It is considered a courtesy to keep your repository fairly recent, to |
||||
lessen any potential merge work Linus may need to do. |
||||
|
||||
|
||||
4) Split up your changes. Each maintainer<->Linus situation is likely |
||||
to be slightly different here, so take this just as general advice. The |
||||
author splits up changes according to "themes" when merging with Linus. |
||||
Simultaneous pushes from local development go to special trees which |
||||
exist solely to house changes "queued" for Linus. Example of the trees: |
||||
|
||||
net-drivers-2.5 -- on-going net driver maintenance |
||||
vm-2.5 -- VM-related changes |
||||
fs-2.5 -- filesystem-related changes |
||||
|
||||
Linus then has much more freedom for pulling changes. He could (for |
||||
example) issue a "bk pull" on vm-2.5 and fs-2.5 trees, to merge their |
||||
changes, but hold off net-drivers-2.5 because of a change that needs |
||||
more discussion. |
||||
|
||||
Other maintainers may find that a single linus-pull-from tree is |
||||
adequate for passing BK changesets to him. |
||||
|
||||
|
||||
|
||||
Frequently Answered Questions |
||||
----------------------------- |
||||
1) How do I change the e-mail address shown in the changelog? |
||||
A. When you run "bk citool" or "bk commit", set environment |
||||
variables BK_USER and BK_HOST to the desired username |
||||
and host/domain name. |
||||
|
||||
|
||||
2) How do I use tags / get a diff between two kernel versions? |
||||
A. Pass the tags Linus uses to 'bk export'. |
||||
|
||||
ChangeSets are in a forward-progressing order, so it's pretty easy |
||||
to get a snapshot starting and ending at any two points in time. |
||||
Linus puts tags on each release and pre-release, so you could use |
||||
these two examples: |
||||
|
||||
bk export -tpatch -hdu -rv2.5.4,v2.5.5 | less |
||||
# creates patch-2.5.5 essentially |
||||
bk export -tpatch -du -rv2.5.5-pre1,v2.5.5 | less |
||||
# changes from pre1 to final |
||||
|
||||
A tag is just an alias for a specific changeset... and since changesets |
||||
are ordered, a tag is thus a marker for a specific point in time (or |
||||
specific state of the tree). |
||||
|
||||
|
||||
3) Is there an easy way to generate One Big Patch versus mainline, |
||||
for my long-lived kernel branch? |
||||
A. Yes. This requires BK 3.x, though. |
||||
|
||||
bk export -tpatch -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+ |
||||
|
||||
@ -0,0 +1,34 @@
|
||||
#!/bin/sh -e |
||||
# DIR=$HOME/BK/axp-2.5 |
||||
# cd $DIR |
||||
|
||||
LINUS_REPO=$1 |
||||
DIRBASE=`basename $PWD` |
||||
|
||||
{ |
||||
cat <<EOT |
||||
Please do a |
||||
|
||||
bk pull bk://gkernel.bkbits.net/$DIRBASE |
||||
|
||||
This will update the following files: |
||||
|
||||
EOT |
||||
|
||||
bk export -tpatch -hdu -r`bk repogca $LINUS_REPO`,+ | diffstat -p1 2>/dev/null |
||||
|
||||
cat <<EOT |
||||
|
||||
through these ChangeSets: |
||||
|
||||
EOT |
||||
|
||||
bk changes -L -d'$unless(:MERGE:){ChangeSet|:CSETREV:\n}' $LINUS_REPO | |
||||
bk -R prs -h -d'$unless(:MERGE:){<:P:@:HOST:> (:D: :I:)\n$each(:C:){ (:C:)\n}\n}' - |
||||
|
||||
} > /tmp/linus.txt |
||||
|
||||
cat <<EOT |
||||
Mail text in /tmp/linus.txt; please check and send using your favourite |
||||
mailer. |
||||
EOT |
||||
@ -0,0 +1,36 @@
|
||||
#!/bin/sh |
||||
# A script to format BK changeset output in a manner that is easy to read. |
||||
# Andreas Dilger <adilger@turbolabs.com> 13/02/2002 |
||||
# |
||||
# Add diffstat output after Changelog <adilger@turbolabs.com> 21/02/2002 |
||||
|
||||
PROG=bksend |
||||
|
||||
usage() { |
||||
echo "usage: $PROG -r<rev>" |
||||
echo -e "\twhere <rev> is of the form '1.23', '1.23..', '1.23..1.27'," |
||||
echo -e "\tor '+' to indicate the most recent revision" |
||||
|
||||
exit 1 |
||||
} |
||||
|
||||
case $1 in |
||||
-r) REV=$2; shift ;; |
||||
-r*) REV=`echo $1 | sed 's/^-r//'` ;; |
||||
*) echo "$PROG: no revision given, you probably don't want that";; |
||||
esac |
||||
|
||||
[ -z "$REV" ] && usage |
||||
|
||||
echo "You can import this changeset into BK by piping this whole message to:" |
||||
echo "'| bk receive [path to repository]' or apply the patch as usual." |
||||
|
||||
SEP="\n===================================================================\n\n" |
||||
echo -e $SEP |
||||
env PAGER=/bin/cat bk changes -r$REV |
||||
echo |
||||
bk export -tpatch -du -h -r$REV | diffstat |
||||
echo; echo |
||||
bk export -tpatch -du -h -r$REV |
||||
echo -e $SEP |
||||
bk send -wgzip_uu -r$REV - |
||||
@ -0,0 +1,41 @@
|
||||
#!/bin/sh |
||||
|
||||
# bz64wrap - the sending side of a bzip2 | base64 stream |
||||
# Andreas Dilger <adilger@clusterfs.com> Jan 2002 |
||||
|
||||
|
||||
PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin |
||||
|
||||
# A program to generate base64 encoding on stdout |
||||
BASE64_ENCODE="uuencode -m /dev/stdout" |
||||
BASE64_BEGIN= |
||||
BASE64_END= |
||||
|
||||
BZIP=NO |
||||
BASE64=NO |
||||
|
||||
# Test if we have the bzip program installed |
||||
bzip2 -c /dev/null > /dev/null 2>&1 && BZIP=YES |
||||
|
||||
# Test if uuencode can handle the -m (MIME) encoding option |
||||
$BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES |
||||
|
||||
if [ $BASE64 = NO ]; then |
||||
BASE64_ENCODE=mimencode |
||||
BASE64_BEGIN="begin-base64 644 -" |
||||
BASE64_END="====" |
||||
|
||||
$BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES |
||||
fi |
||||
|
||||
if [ $BZIP = NO -o $BASE64 = NO ]; then |
||||
echo "$0: can't use bz64 encoding: bzip2=$BZIP, $BASE64_ENCODE=$BASE64" |
||||
exit 1 |
||||
fi |
||||
|
||||
# Sadly, mimencode does not appear to have good "begin" and "end" markers |
||||
# like uuencode does, and it is picky about getting the right start/end of |
||||
# the base64 stream, so we handle this internally. |
||||
echo "$BASE64_BEGIN" |
||||
bzip2 -9 | $BASE64_ENCODE |
||||
echo "$BASE64_END" |
||||
@ -0,0 +1,36 @@
|
||||
#!/bin/sh |
||||
# |
||||
# Purpose: Copy changeset patch and description from one |
||||
# repository to another, unrelated one. |
||||
# |
||||
# usage: cpcset [revision] [from-repository] [to-repository] |
||||
# |
||||
|
||||
REV=$1 |
||||
FROM=$2 |
||||
TO=$3 |
||||
TMPF=/tmp/cpcset.$$ |
||||
|
||||
rm -f $TMPF* |
||||
|
||||
CWD_SAVE=`pwd` |
||||
cd $FROM |
||||
bk changes -r$REV | \ |
||||
grep -v '^ChangeSet' | \ |
||||
sed -e 's/^ //g' > $TMPF.log |
||||
|
||||
USERHOST=`bk changes -r$REV | grep '^ChangeSet' | awk '{print $4}'` |
||||
export BK_USER=`echo $USERHOST | awk '-F@' '{print $1}'` |
||||
export BK_HOST=`echo $USERHOST | awk '-F@' '{print $2}'` |
||||
|
||||
bk export -tpatch -hdu -r$REV > $TMPF.patch && \ |
||||
cd $CWD_SAVE && \ |
||||
cd $TO && \ |
||||
bk import -tpatch -CFR -y"`cat $TMPF.log`" $TMPF.patch . && \ |
||||
bk commit -y"`cat $TMPF.log`" |
||||
|
||||
rm -f $TMPF* |
||||
|
||||
echo changeset $REV copied. |
||||
echo "" |
||||
|
||||
@ -0,0 +1,49 @@
|
||||
#!/usr/bin/perl -w |
||||
|
||||
use strict; |
||||
|
||||
my ($lhs, $rev, $tmp, $rhs, $s); |
||||
my @cset_text = (); |
||||
my @pipe_text = (); |
||||
my $have_cset = 0; |
||||
|
||||
while (<>) { |
||||
next if /^---/; |
||||
|
||||
if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) { |
||||
&cset_rev if ($have_cset); |
||||
|
||||
$rev = $tmp; |
||||
$have_cset = 1; |
||||
|
||||
push(@cset_text, $_); |
||||
} |
||||
|
||||
elsif ($have_cset) { |
||||
push(@cset_text, $_); |
||||
} |
||||
} |
||||
&cset_rev if ($have_cset); |
||||
exit(0); |
||||
|
||||
|
||||
sub cset_rev { |
||||
my $empty_cset = 0; |
||||
|
||||
open PIPE, "bk export -tpatch -hdu -r $rev | diffstat -p1 2>/dev/null |" or die; |
||||
while ($s = <PIPE>) { |
||||
$empty_cset = 1 if ($s =~ /0 files changed/); |
||||
push(@pipe_text, $s); |
||||
} |
||||
close(PIPE); |
||||
|
||||
if (! $empty_cset) { |
||||
print @cset_text; |
||||
print @pipe_text; |
||||
print "\n\n"; |
||||
} |
||||
|
||||
@pipe_text = (); |
||||
@cset_text = (); |
||||
} |
||||
|
||||
@ -0,0 +1,44 @@
|
||||
#!/usr/bin/perl -w |
||||
|
||||
use strict; |
||||
|
||||
my ($lhs, $rev, $tmp, $rhs, $s); |
||||
my @cset_text = (); |
||||
my @pipe_text = (); |
||||
my $have_cset = 0; |
||||
|
||||
while (<>) { |
||||
next if /^---/; |
||||
|
||||
if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) { |
||||
&cset_rev if ($have_cset); |
||||
|
||||
$rev = $tmp; |
||||
$have_cset = 1; |
||||
|
||||
push(@cset_text, $_); |
||||
} |
||||
|
||||
elsif ($have_cset) { |
||||
push(@cset_text, $_); |
||||
} |
||||
} |
||||
&cset_rev if ($have_cset); |
||||
exit(0); |
||||
|
||||
|
||||
sub cset_rev { |
||||
my $empty_cset = 0; |
||||
|
||||
system("bk export -tpatch -du -r $rev > /tmp/rev-$rev.patch"); |
||||
|
||||
if (! $empty_cset) { |
||||
print @cset_text; |
||||
print @pipe_text; |
||||
print "\n\n"; |
||||
} |
||||
|
||||
@pipe_text = (); |
||||
@cset_text = (); |
||||
} |
||||
|
||||
@ -0,0 +1,8 @@
|
||||
#!/bin/sh |
||||
# |
||||
# Purpose: Generate GNU diff of local changes versus canonical top-of-tree |
||||
# |
||||
# Usage: gcapatch > foo.patch |
||||
# |
||||
|
||||
bk export -tpatch -hdu -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+ |
||||
@ -0,0 +1,25 @@
|
||||
#!/bin/sh |
||||
|
||||
# unbz64wrap - the receiving side of a bzip2 | base64 stream |
||||
# Andreas Dilger <adilger@clusterfs.com> Jan 2002 |
||||
|
||||
# Sadly, mimencode does not appear to have good "begin" and "end" markers |
||||
# like uuencode does, and it is picky about getting the right start/end of |
||||
# the base64 stream, so we handle this explicitly here. |
||||
|
||||
PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin |
||||
|
||||
if mimencode -u < /dev/null > /dev/null 2>&1 ; then |
||||
SHOW= |
||||
while read LINE; do |
||||
case $LINE in |
||||
begin-base64*) SHOW=YES ;; |
||||
====) SHOW= ;; |
||||
*) [ "$SHOW" ] && echo "$LINE" ;; |
||||
esac |
||||
done | mimencode -u | bunzip2 |
||||
exit $? |
||||
else |
||||
cat - | uudecode -o /dev/stdout | bunzip2 |
||||
exit $? |
||||
fi |
||||
@ -0,0 +1,92 @@
|
||||
[Sat Mar 2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)] |
||||
|
||||
This is how to track down a bug if you know nothing about kernel hacking. |
||||
It's a brute force approach but it works pretty well. |
||||
|
||||
You need: |
||||
|
||||
. A reproducible bug - it has to happen predictably (sorry) |
||||
. All the kernel tar files from a revision that worked to the |
||||
revision that doesn't |
||||
|
||||
You will then do: |
||||
|
||||
. Rebuild a revision that you believe works, install, and verify that. |
||||
. Do a binary search over the kernels to figure out which one |
||||
introduced the bug. I.e., suppose 1.3.28 didn't have the bug, but |
||||
you know that 1.3.69 does. Pick a kernel in the middle and build |
||||
that, like 1.3.50. Build & test; if it works, pick the mid point |
||||
between .50 and .69, else the mid point between .28 and .50. |
||||
. You'll narrow it down to the kernel that introduced the bug. You |
||||
can probably do better than this but it gets tricky. |
||||
|
||||
. Narrow it down to a subdirectory |
||||
|
||||
- Copy kernel that works into "test". Let's say that 3.62 works, |
||||
but 3.63 doesn't. So you diff -r those two kernels and come |
||||
up with a list of directories that changed. For each of those |
||||
directories: |
||||
|
||||
Copy the non-working directory next to the working directory |
||||
as "dir.63". |
||||
One directory at time, try moving the working directory to |
||||
"dir.62" and mv dir.63 dir"time, try |
||||
|
||||
mv dir dir.62 |
||||
mv dir.63 dir |
||||
find dir -name '*.[oa]' -print | xargs rm -f |
||||
|
||||
And then rebuild and retest. Assuming that all related |
||||
changes were contained in the sub directory, this should |
||||
isolate the change to a directory. |
||||
|
||||
Problems: changes in header files may have occurred; I've |
||||
found in my case that they were self explanatory - you may |
||||
or may not want to give up when that happens. |
||||
|
||||
. Narrow it down to a file |
||||
|
||||
- You can apply the same technique to each file in the directory, |
||||
hoping that the changes in that file are self contained. |
||||
|
||||
. Narrow it down to a routine |
||||
|
||||
- You can take the old file and the new file and manually create |
||||
a merged file that has |
||||
|
||||
#ifdef VER62 |
||||
routine() |
||||
{ |
||||
... |
||||
} |
||||
#else |
||||
routine() |
||||
{ |
||||
... |
||||
} |
||||
#endif |
||||
|
||||
And then walk through that file, one routine at a time and |
||||
prefix it with |
||||
|
||||
#define VER62 |
||||
/* both routines here */ |
||||
#undef VER62 |
||||
|
||||
Then recompile, retest, move the ifdefs until you find the one |
||||
that makes the difference. |
||||
|
||||
Finally, you take all the info that you have, kernel revisions, bug |
||||
description, the extent to which you have narrowed it down, and pass |
||||
that off to whomever you believe is the maintainer of that section. |
||||
A post to linux.dev.kernel isn't such a bad idea if you've done some |
||||
work to narrow it down. |
||||
|
||||
If you get it down to a routine, you'll probably get a fix in 24 hours. |
||||
|
||||
My apologies to Linus and the other kernel hackers for describing this |
||||
brute force approach, it's hardly what a kernel hacker would do. However, |
||||
it does work and it lets non-hackers help fix bugs. And it is cool |
||||
because Linux snapshots will let you do this - something that you can't |
||||
do with vendor supplied releases. |
||||
|
||||
@ -0,0 +1,410 @@
|
||||
Intro |
||||
===== |
||||
|
||||
This document is designed to provide a list of the minimum levels of |
||||
software necessary to run the 2.6 kernels, as well as provide brief |
||||
instructions regarding any other "Gotchas" users may encounter when |
||||
trying life on the Bleeding Edge. If upgrading from a pre-2.4.x |
||||
kernel, please consult the Changes file included with 2.4.x kernels for |
||||
additional information; most of that information will not be repeated |
||||
here. Basically, this document assumes that your system is already |
||||
functional and running at least 2.4.x kernels. |
||||
|
||||
This document is originally based on my "Changes" file for 2.0.x kernels |
||||
and therefore owes credit to the same people as that file (Jared Mauch, |
||||
Axel Boldt, Alessandro Sigala, and countless other users all over the |
||||
'net). |
||||
|
||||
The latest revision of this document, in various formats, can always |
||||
be found at <http://cyberbuzz.gatech.edu/kaboom/linux/Changes-2.4/>. |
||||
|
||||
Feel free to translate this document. If you do so, please send me a |
||||
URL to your translation for inclusion in future revisions of this |
||||
document. |
||||
|
||||
Smotrite file <http://oblom.rnc.ru/linux/kernel/Changes.ru>, yavlyaushisya |
||||
russkim perevodom dannogo documenta. |
||||
|
||||
Visite <http://www2.adi.uam.es/~ender/tecnico/> para obtener la traducciรณn |
||||
al espaรฑol de este documento en varios formatos. |
||||
|
||||
Eine deutsche Version dieser Datei finden Sie unter |
||||
<http://www.stefan-winter.de/Changes-2.4.0.txt>. |
||||
|
||||
Last updated: October 29th, 2002 |
||||
|
||||
Chris Ricker (kaboom@gatech.edu or chris.ricker@genetics.utah.edu). |
||||
|
||||
Current Minimal Requirements |
||||
============================ |
||||
|
||||
Upgrade to at *least* these software revisions before thinking you've |
||||
encountered a bug! If you're unsure what version you're currently |
||||
running, the suggested command should tell you. |
||||
|
||||
Again, keep in mind that this list assumes you are already |
||||
functionally running a Linux 2.4 kernel. Also, not all tools are |
||||
necessary on all systems; obviously, if you don't have any PCMCIA (PC |
||||
Card) hardware, for example, you probably needn't concern yourself |
||||
with pcmcia-cs. |
||||
|
||||
o Gnu C 2.95.3 # gcc --version |
||||
o Gnu make 3.79.1 # make --version |
||||
o binutils 2.12 # ld -v |
||||
o util-linux 2.10o # fdformat --version |
||||
o module-init-tools 0.9.10 # depmod -V |
||||
o e2fsprogs 1.29 # tune2fs |
||||
o jfsutils 1.1.3 # fsck.jfs -V |
||||
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs |
||||
o xfsprogs 2.6.0 # xfs_db -V |
||||
o pcmcia-cs 3.1.21 # cardmgr -V |
||||
o quota-tools 3.09 # quota -V |
||||
o PPP 2.4.0 # pppd --version |
||||
o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version |
||||
o nfs-utils 1.0.5 # showmount --version |
||||
o procps 3.2.0 # ps --version |
||||
o oprofile 0.5.3 # oprofiled --version |
||||
|
||||
Kernel compilation |
||||
================== |
||||
|
||||
GCC |
||||
--- |
||||
|
||||
The gcc version requirements may vary depending on the type of CPU in your |
||||
computer. The next paragraph applies to users of x86 CPUs, but not |
||||
necessarily to users of other CPUs. Users of other CPUs should obtain |
||||
information about their gcc version requirements from another source. |
||||
|
||||
The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it |
||||
should be used when you need absolute stability. You may use gcc 3.0.x |
||||
instead if you wish, although it may cause problems. Later versions of gcc |
||||
have not received much testing for Linux kernel compilation, and there are |
||||
almost certainly bugs (mainly, but not exclusively, in the kernel) that |
||||
will need to be fixed in order to use these compilers. In any case, using |
||||
pgcc instead of plain gcc is just asking for trouble. |
||||
|
||||
The Red Hat gcc 2.96 compiler subtree can also be used to build this tree. |
||||
You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build |
||||
the kernel correctly. |
||||
|
||||
In addition, please pay attention to compiler optimization. Anything |
||||
greater than -O2 may not be wise. Similarly, if you choose to use gcc-2.95.x |
||||
or derivatives, be sure not to use -fstrict-aliasing (which, depending on |
||||
your version of gcc 2.95.x, may necessitate using -fno-strict-aliasing). |
||||
|
||||
Make |
||||
---- |
||||
|
||||
You will need Gnu make 3.79.1 or later to build the kernel. |
||||
|
||||
Binutils |
||||
-------- |
||||
|
||||
Linux on IA-32 has recently switched from using as86 to using gas for |
||||
assembling the 16-bit boot code, removing the need for as86 to compile |
||||
your kernel. This change does, however, mean that you need a recent |
||||
release of binutils. |
||||
|
||||
System utilities |
||||
================ |
||||
|
||||
Architectural changes |
||||
--------------------- |
||||
|
||||
DevFS has been obsoleted in favour of udev |
||||
(http://www.kernel.org/pub/linux/utils/kernel/hotplug/) |
||||
|
||||
32-bit UID support is now in place. Have fun! |
||||
|
||||
Linux documentation for functions is transitioning to inline |
||||
documentation via specially-formatted comments near their |
||||
definitions in the source. These comments can be combined with the |
||||
SGML templates in the Documentation/DocBook directory to make DocBook |
||||
files, which can then be converted by DocBook stylesheets to PostScript, |
||||
HTML, PDF files, and several other formats. In order to convert from |
||||
DocBook format to a format of your choice, you'll need to install Jade as |
||||
well as the desired DocBook stylesheets. |
||||
|
||||
Util-linux |
||||
---------- |
||||
|
||||
New versions of util-linux provide *fdisk support for larger disks, |
||||
support new options to mount, recognize more supported partition |
||||
types, have a fdformat which works with 2.4 kernels, and similar goodies. |
||||
You'll probably want to upgrade. |
||||
|
||||
Ksymoops |
||||
-------- |
||||
|
||||
If the unthinkable happens and your kernel oopses, you'll need a 2.4 |
||||
version of ksymoops to decode the report; see REPORTING-BUGS in the |
||||
root of the Linux source for more information. |
||||
|
||||
Module-Init-Tools |
||||
----------------- |
||||
|
||||
A new module loader is now in the kernel that requires module-init-tools |
||||
to use. It is backward compatible with the 2.4.x series kernels. |
||||
|
||||
Mkinitrd |
||||
-------- |
||||
|
||||
These changes to the /lib/modules file tree layout also require that |
||||
mkinitrd be upgraded. |
||||
|
||||
E2fsprogs |
||||
--------- |
||||
|
||||
The latest version of e2fsprogs fixes several bugs in fsck and |
||||
debugfs. Obviously, it's a good idea to upgrade. |
||||
|
||||
JFSutils |
||||
-------- |
||||
|
||||
The jfsutils package contains the utilities for the file system. |
||||
The following utilities are available: |
||||
o fsck.jfs - initiate replay of the transaction log, and check |
||||
and repair a JFS formatted partition. |
||||
o mkfs.jfs - create a JFS formatted partition. |
||||
o other file system utilities are also available in this package. |
||||
|
||||
Reiserfsprogs |
||||
------------- |
||||
|
||||
The reiserfsprogs package should be used for reiserfs-3.6.x |
||||
(Linux kernels 2.4.x). It is a combined package and contains working |
||||
versions of mkreiserfs, resize_reiserfs, debugreiserfs and |
||||
reiserfsck. These utils work on both i386 and alpha platforms. |
||||
|
||||
Xfsprogs |
||||
-------- |
||||
|
||||
The latest version of xfsprogs contains mkfs.xfs, xfs_db, and the |
||||
xfs_repair utilities, among others, for the XFS filesystem. It is |
||||
architecture independent and any version from 2.0.0 onward should |
||||
work correctly with this version of the XFS kernel code (2.6.0 or |
||||
later is recommended, due to some significant improvements). |
||||
|
||||
|
||||
Pcmcia-cs |
||||
--------- |
||||
|
||||
PCMCIA (PC Card) support is now partially implemented in the main |
||||
kernel source. Pay attention when you recompile your kernel ;-). |
||||
Also, be sure to upgrade to the latest pcmcia-cs release. |
||||
|
||||
Quota-tools |
||||
----------- |
||||
|
||||
Support for 32 bit uid's and gid's is required if you want to use |
||||
the newer version 2 quota format. Quota-tools version 3.07 and |
||||
newer has this support. Use the recommended version or newer |
||||
from the table above. |
||||
|
||||
Intel IA32 microcode |
||||
-------------------- |
||||
|
||||
A driver has been added to allow updating of Intel IA32 microcode, |
||||
accessible as both a devfs regular file and as a normal (misc) |
||||
character device. If you are not using devfs you may need to: |
||||
|
||||
mkdir /dev/cpu |
||||
mknod /dev/cpu/microcode c 10 184 |
||||
chmod 0644 /dev/cpu/microcode |
||||
|
||||
as root before you can use this. You'll probably also want to |
||||
get the user-space microcode_ctl utility to use with this. |
||||
|
||||
Powertweak |
||||
---------- |
||||
|
||||
If you are running v0.1.17 or earlier, you should upgrade to |
||||
version v0.99.0 or higher. Running old versions may cause problems |
||||
with programs using shared memory. |
||||
|
||||
udev |
||||
---- |
||||
udev is a userspace application for populating /dev dynamically with |
||||
only entries for devices actually present. udev replaces devfs. |
||||
|
||||
Networking |
||||
========== |
||||
|
||||
General changes |
||||
--------------- |
||||
|
||||
If you have advanced network configuration needs, you should probably |
||||
consider using the network tools from ip-route2. |
||||