[PATCH] docs: ramdisk/initrd/initramfs corrections

[PATCH] docs: ramdisk/initrd/initramfs corrections

[Randy Dunlap]

From: Randy Dunlap <randy.dunlap@oracle.com>

initrd/initramfs/ramdisk docs:
- fix typos/spellos/grammar
- clarify RAM disk config location
- correct cpio option

Cc: Bryan O'Sullivan <bos@serpentine.com>
Cc: Rob Landley <rob@landley.net>
Cc: Werner Almesberger <werner@almesberger.net>
Cc: H. Peter Anvin <hpa@zytor.com>

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 Documentation/early-userspace/README                 |    6 +++---
 Documentation/filesystems/ramfs-rootfs-initramfs.txt |   14 +++++++-------
 Documentation/initrd.txt                             |   12 ++++++------
 Documentation/ramdisk.txt                            |   17 +++++++++++------
 4 files changed, 27 insertions(+), 22 deletions(-)

--- linux-2.6.23-rc4.orig/Documentation/ramdisk.txt
+++ linux-2.6.23-rc4/Documentation/ramdisk.txt
@@ -22,16 +22,21 @@ The RAM disk dynamically grows as more s
 RAM from the buffer cache. The driver marks the buffers it is using as dirty
 so that the VM subsystem does not try to reclaim them later.
 
-Also, the RAM disk supports up to 16 RAM disks out of the box, and can
-be reconfigured to support up to 255 RAM disks - change "#define NUM_RAMDISKS"
-in drivers/block/rd.c.  To use RAM disk support with your system, run
-'./MAKEDEV ram' from the /dev directory.  RAM disks are all major number 1, and
-start with minor number 0 for /dev/ram0, etc.  If used, modern kernels use
-/dev/ram0 for an initrd.
+The RAM disk supports up to 16 RAM disks by default, and can be reconfigured
+to support an unlimited number of RAM disks (at your own risk).  Just change
+the configuration symbol BLK_DEV_RAM_COUNT in the Block drivers config menu
+and (re)build the kernel.
+
+To use RAM disk support with your system, run './MAKEDEV ram' from the /dev
+directory.  RAM disks are all major number 1, and start with minor number 0
+for /dev/ram0, etc.  If used, modern kernels use /dev/ram0 for an initrd.
 
 The old "ramdisk=<ram_size>" has been changed to "ramdisk_size=<ram_size>" to
 make it clearer.  The original "ramdisk=<ram_size>" has been kept around for
 compatibility reasons, but it may be removed in the future.
+There are also config symbols (in the Block drivers config menu) for these
+variables:  BLK_DEV_RAM_SIZE defaults to 4096 and BLK_DEV_RAM_BLOCKSIZE
+defaults to 1024.
 
 The new RAM disk also has the ability to load compressed RAM disk images,
 allowing one to squeeze more programs onto an average installation or
--- linux-2.6.23-rc4.orig/Documentation/initrd.txt
+++ linux-2.6.23-rc4/Documentation/initrd.txt
@@ -80,8 +80,8 @@ Compressed cpio images
 ----------------------
 
 Recent kernels have support for populating a ramdisk from a compressed cpio
-archive, on such systems, the creation of a ramdisk image doesn't need to
-involve special block devices or loopbacks, you merely create a directory on
+archive. On such systems, the creation of a ramdisk image doesn't need to
+involve special block devices or loopbacks; you merely create a directory on
 disk with the desired initrd content, cd to that directory, and run (as an
 example):
 
@@ -293,7 +293,7 @@ information as small as possible. In thi
 generated with all the necessary modules. Then, only /sbin/init or a file
 read by it would have to be different.
 
-A third scenario are more convenient recovery disks, because information
+A third scenario is more convenient recovery disks, because information
 like the location of the root FS partition doesn't have to be provided at
 boot time, but the system loaded from initrd can invoke a user-friendly
 dialog and it can also perform some sanity checks (or even some form of
@@ -339,8 +339,8 @@ the new, supported mechanism is called "
 Mixed change_root and pivot_root mechanism
 ------------------------------------------
 
-In case you did not want to use root=/dev/ram0 to trig the pivot_root mechanism,
-you may create both /linuxrc and /sbin/init in your initrd image.
+In case you did not want to use root=/dev/ram0 to trigger the pivot_root
+mechanism, you may create both /linuxrc and /sbin/init in your initrd image.
 
 /linuxrc would contain only the following:
 
@@ -350,7 +350,7 @@ echo 0x0100 >/proc/sys/kernel/real-root-
 umount -n /proc
 
 Once linuxrc exited, the kernel would mount again your initrd as root,
-this time executing /sbin/init. Again, it would be duty of this init
+this time executing /sbin/init. Again, it would be the duty of this init
 to build the right environment (maybe using the root= device passed on
 the cmdline) before the final execution of the real /sbin/init.
 
--- linux-2.6.23-rc4.orig/Documentation/filesystems/ramfs-rootfs-initramfs.txt
+++ linux-2.6.23-rc4/Documentation/filesystems/ramfs-rootfs-initramfs.txt
@@ -8,7 +8,7 @@ What is ramfs?
 
 Ramfs is a very simple filesystem that exports Linux's disk caching
 mechanisms (the page cache and dentry cache) as a dynamically resizable
-ram-based filesystem.
+RAM-based filesystem.
 
 Normally all files are cached in memory by Linux.  Pages of data read from
 backing store (usually the block device the filesystem is mounted on) are kept
@@ -34,7 +34,7 @@ ramfs and ramdisk:
 ------------------
 
 The older "ram disk" mechanism created a synthetic block device out of
-an area of ram and used it as backing store for a filesystem.  This block
+an area of RAM and used it as backing store for a filesystem.  This block
 device was of fixed size, so the filesystem mounted on it was of fixed
 size.  Using a ram disk also required unnecessarily copying memory from the
 fake block device into the page cache (and copying changes back out), as well
@@ -46,8 +46,8 @@ unnecessary work for the CPU, and pollut
 to avoid this copying by playing with the page tables, but they're unpleasantly
 complicated and turn out to be about as expensive as the copying anyway.)
 More to the point, all the work ramfs is doing has to happen _anyway_,
-since all file access goes through the page and dentry caches.  The ram
-disk is simply unnecessary, ramfs is internally much simpler.
+since all file access goes through the page and dentry caches.  The RAM
+disk is simply unnecessary; ramfs is internally much simpler.
 
 Another reason ramdisks are semi-obsolete is that the introduction of
 loopback devices offered a more flexible and convenient way to create
@@ -103,7 +103,7 @@ All this differs from the old initrd in 
     initramfs archive is a gzipped cpio archive (like tar only simpler,
     see cpio(1) and Documentation/early-userspace/buffer-format.txt).  The
     kernel's cpio extraction code is not only extremely small, it's also
-    __init data that can be discarded during the boot process.
+    __init text and data that can be discarded during the boot process.
 
   - The program run by the old initrd (which was called /initrd, not /init) did
     some setup and then returned to the kernel, while the init program from
@@ -220,7 +220,7 @@ device) but the separate packaging of in
 non-GPL code you'd like to run from initramfs, without conflating it with
 the GPL licensed Linux kernel binary).
 
-It can also be used to supplement the kernel's built-in initamfs image.  The
+It can also be used to supplement the kernel's built-in initramfs image.  The
 files in the external archive will overwrite any conflicting files in
 the built-in initramfs archive.  Some distributors also prefer to customize
 a single kernel image with task-specific initramfs images, without recompiling.
@@ -339,7 +339,7 @@ smooth transition and allowing early boo
 The move to early userspace is necessary because finding and mounting the real
 root device is complex.  Root partitions can span multiple devices (raid or
 separate journal).  They can be out on the network (requiring dhcp, setting a
-specific mac address, logging into a server, etc).  They can live on removable
+specific MAC address, logging into a server, etc).  They can live on removable
 media, with dynamically allocated major/minor numbers and persistent naming
 issues requiring a full udev implementation to sort out.  They can be
 compressed, encrypted, copy-on-write, loopback mounted, strangely partitioned,
--- linux-2.6.23-rc4.orig/Documentation/early-userspace/README
+++ linux-2.6.23-rc4/Documentation/early-userspace/README
@@ -19,7 +19,7 @@ It consists of several major infrastruct
 - klibc, a userspace C library, currently packaged separately, that is
   optimized for correctness and small size.
 
-The cpio file format used by initramfs is the "newc" (aka "cpio -c")
+The cpio file format used by initramfs is the "newc" (aka "cpio -H newc")
 format, and is documented in the file "buffer-format.txt".  There are
 two ways to add an early userspace image: specify an existing cpio
 archive to be used as the image or have the kernel build process build
@@ -44,7 +44,7 @@ The image is specified as one or more so
 CONFIG_INITRAMFS_SOURCE.  Sources can be either directories or files -
 cpio archives are *not* allowed when building from sources.
 
-A source directory will have it and all of it's contents packaged.  The
+A source directory will have it and all of its contents packaged.  The
 specified directory name will be mapped to '/'.  When packaging a
 directory, limited user and group ID translation can be performed.
 INITRAMFS_ROOT_UID can be set to a user ID that needs to be mapped to
@@ -144,7 +144,7 @@ c) using initramfs.  The call to prepare
    initrd format, an cpio archive.  It must be called "/init".  This binary
    is responsible to do all the things prepare_namespace() would do.
 
-   To remain backwards compatibility, the /init binary will only run if it
+   To maintain backwards compatibility, the /init binary will only run if it
    comes via an initramfs cpio archive.  If this is not the case,
    init/main.c:init() will run prepare_namespace() to mount the final root
    and exec one of the predefined init binaries.

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Robert P. J. Day]

On Thu, 30 Aug 2007, Randy Dunlap wrote:

...
> The old "ramdisk=<ram_size>" has been changed to
> "ramdisk_size=<ram_size>" to make it clearer.  The original
> "ramdisk=<ram_size>" has been kept around for compatibility reasons,
> but it may be removed in the future.
...

i just the other day submitted a patch to remove that backward
compatibility, and the m68k portion of it has already been acked by
geert uytterhoeven.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Bryan O'Sullivan]

Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> initrd/initramfs/ramdisk docs:
> - fix typos/spellos/grammar
> - clarify RAM disk config location
> - correct cpio option
> 
> Cc: Bryan O'Sullivan <bos@serpentine.com>

Acked-by: Bryan O'Sullivan <bos@serpentine.com>

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[H. Peter Anvin]

Rob Landley wrote:
> On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
>> On Thu, 30 Aug 2007, Randy Dunlap wrote:
>>
>> ...
>>
>>> The old "ramdisk=<ram_size>" has been changed to
>>> "ramdisk_size=<ram_size>" to make it clearer.  The original
>>> "ramdisk=<ram_size>" has been kept around for compatibility reasons,
>>> but it may be removed in the future.
>> ...
>>
>> i just the other day submitted a patch to remove that backward
>> compatibility, and the m68k portion of it has already been acked by
>> geert uytterhoeven.
> 
> Could you mention it in feature-removal-schedule.txt?  (People check that for 
> warning of upcoming changes that impact existing code.  They may not notice 
> something elsewhere after they've got it working...)
> 

The same objection applies to this as to the previous one.  In that 
respect, an Ack from a maintainer of an almost unused architecture is 
meaningless (sorry, Geert.)

	-hpa

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Randy Dunlap]

On Thu, 30 Aug 2007 15:41:27 -0700 H. Peter Anvin wrote:

> Rob Landley wrote:
> > On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
> >> On Thu, 30 Aug 2007, Randy Dunlap wrote:
> >>
> >> ...
> >>
> >>> The old "ramdisk=<ram_size>" has been changed to
> >>> "ramdisk_size=<ram_size>" to make it clearer.  The original
> >>> "ramdisk=<ram_size>" has been kept around for compatibility reasons,
> >>> but it may be removed in the future.
> >> ...
> >>
> >> i just the other day submitted a patch to remove that backward
> >> compatibility, and the m68k portion of it has already been acked by
> >> geert uytterhoeven.

I couldn't find it.  Can you provide a pointer to it?

> > Could you mention it in feature-removal-schedule.txt?  (People check that for 
> > warning of upcoming changes that impact existing code.  They may not notice 
> > something elsewhere after they've got it working...)
> > 
> 
> The same objection applies to this as to the previous one.  In that 
> respect, an Ack from a maintainer of an almost unused architecture is 
> meaningless (sorry, Geert.)

Peter, what are you objecting to, Rob's comment, Robert's comment,
Robert's patch, or my patch?

Thanks.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[H. Peter Anvin]

Randy Dunlap wrote:
> On Thu, 30 Aug 2007 15:41:27 -0700 H. Peter Anvin wrote:
> 
>> Rob Landley wrote:
>>> On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
>>>> On Thu, 30 Aug 2007, Randy Dunlap wrote:
>>>>
>>>> ...
>>>>
>>>>> The old "ramdisk=<ram_size>" has been changed to
>>>>> "ramdisk_size=<ram_size>" to make it clearer.  The original
>>>>> "ramdisk=<ram_size>" has been kept around for compatibility reasons,
>>>>> but it may be removed in the future.
>>>> ...
>>>>
>>>> i just the other day submitted a patch to remove that backward
>>>> compatibility, and the m68k portion of it has already been acked by
>>>> geert uytterhoeven.
> 
> I couldn't find it.  Can you provide a pointer to it?
> 
>>> Could you mention it in feature-removal-schedule.txt?  (People check that for 
>>> warning of upcoming changes that impact existing code.  They may not notice 
>>> something elsewhere after they've got it working...)
>>>
>> The same objection applies to this as to the previous one.  In that 
>> respect, an Ack from a maintainer of an almost unused architecture is 
>> meaningless (sorry, Geert.)
> 
> Peter, what are you objecting to, Rob's comment, Robert's comment,
> Robert's patch, or my patch?
> 

Robert's patch.

	-hpa

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Rob Landley]

On Thursday 30 August 2007 1:20:55 pm Randy Dunlap wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> initrd/initramfs/ramdisk docs:
> - fix typos/spellos/grammar
> - clarify RAM disk config location
> - correct cpio option
>
> Cc: Bryan O'Sullivan <bos@serpentine.com>
> Cc: Rob Landley <rob@landley.net>
> Cc: Werner Almesberger <werner@almesberger.net>
> Cc: H. Peter Anvin <hpa@zytor.com>
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>

Acked-by: Rob Landley <rob@landley.net>

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Rob Landley]

On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
> On Thu, 30 Aug 2007, Randy Dunlap wrote:
>
> ...
>
> > The old "ramdisk=<ram_size>" has been changed to
> > "ramdisk_size=<ram_size>" to make it clearer.  The original
> > "ramdisk=<ram_size>" has been kept around for compatibility reasons,
> > but it may be removed in the future.
>
> ...
>
> i just the other day submitted a patch to remove that backward
> compatibility, and the m68k portion of it has already been acked by
> geert uytterhoeven.

Could you mention it in feature-removal-schedule.txt?  (People check that for 
warning of upcoming changes that impact existing code.  They may not notice 
something elsewhere after they've got it working...)

(Also, sorting feature-removal-schedule.txt by date would be really nice.  The 
sucker's gotten huge...)

And while I'm looking at this, is there some other place that entries in this 
file go once they _have_ been removed, so people can see "oh yeah, that went 
away in 2.6.23) when they try to install 2.6.25?  If there is, I missed it.  
Maybe http://lwn.net/Articles/2.6-kernel-api/ is good enough, but this seems 
easy to do in Documentation...

Thanks,

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Jesper Juhl]

On 30/08/2007, Randy Dunlap <randy.dunlap@oracle.com> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> initrd/initramfs/ramdisk docs:
> - fix typos/spellos/grammar
> - clarify RAM disk config location
> - correct cpio option
>
> Cc: Bryan O'Sullivan <bos@serpentine.com>
> Cc: Rob Landley <rob@landley.net>
> Cc: Werner Almesberger <werner@almesberger.net>
> Cc: H. Peter Anvin <hpa@zytor.com>
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
...

Hi Randy,

I read through your changes and they seem reasonable to me, so for
what it's worth;

Acked-by: Jesper Juhl <jesper.juhl@gmail.com>


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Robert P. J. Day]

On Thu, 30 Aug 2007, H. Peter Anvin wrote:

> Rob Landley wrote:
> > On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
> > > On Thu, 30 Aug 2007, Randy Dunlap wrote:
> > >
> > > ...
> > >
> > > > The old "ramdisk=<ram_size>" has been changed to
> > > > "ramdisk_size=<ram_size>" to make it clearer.  The original
> > > > "ramdisk=<ram_size>" has been kept around for compatibility reasons,
> > > > but it may be removed in the future.
> > > ...
> > >
> > > i just the other day submitted a patch to remove that backward
> > > compatibility, and the m68k portion of it has already been acked by
> > > geert uytterhoeven.
> >
> > Could you mention it in feature-removal-schedule.txt?  (People
> > check that for warning of upcoming changes that impact existing
> > code.  They may not notice something elsewhere after they've got
> > it working...)
> >
>
> The same objection applies to this as to the previous one.  In that
> respect, an Ack from a maintainer of an almost unused architecture
> is meaningless (sorry, Geert.)

fair enough, but since i posted that patch to LKML three days ago,
someone *could* have NAKed it at the time.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Robert P. J. Day]

On Thu, 30 Aug 2007, Randy Dunlap wrote:

> On Thu, 30 Aug 2007 15:41:27 -0700 H. Peter Anvin wrote:
>
> > Rob Landley wrote:
> > > On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
> > >> On Thu, 30 Aug 2007, Randy Dunlap wrote:
> > >>
> > >> ...
> > >>
> > >>> The old "ramdisk=<ram_size>" has been changed to
> > >>> "ramdisk_size=<ram_size>" to make it clearer.  The original
> > >>> "ramdisk=<ram_size>" has been kept around for compatibility
> > >>> reasons, but it may be removed in the future.
> > >> ...
> > >>
> > >> i just the other day submitted a patch to remove that backward
> > >> compatibility, and the m68k portion of it has already been
> > >> acked by geert uytterhoeven.
>
> I couldn't find it.  Can you provide a pointer to it?

sure.  http://marc.info/?l=linux-kernel&m=118828410509208&w=2
>
> > > Could you mention it in feature-removal-schedule.txt?  (People
> > > check that for warning of upcoming changes that impact existing
> > > code.  They may not notice something elsewhere after they've got
> > > it working...)
> > >
> >
> > The same objection applies to this as to the previous one.  In
> > that respect, an Ack from a maintainer of an almost unused
> > architecture is meaningless (sorry, Geert.)
>
> Peter, what are you objecting to, Rob's comment, Robert's comment,
> Robert's patch, or my patch?

i'm sure he's objecting to my aforementioned patch.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Robert P. J. Day]

On Thu, 30 Aug 2007, Rob Landley wrote:

> On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
> > On Thu, 30 Aug 2007, Randy Dunlap wrote:
> >
> > ...
> >
> > > The old "ramdisk=<ram_size>" has been changed to
> > > "ramdisk_size=<ram_size>" to make it clearer.  The original
> > > "ramdisk=<ram_size>" has been kept around for compatibility reasons,
> > > but it may be removed in the future.
> >
> > ...
> >
> > i just the other day submitted a patch to remove that backward
> > compatibility, and the m68k portion of it has already been acked
> > by geert uytterhoeven.
>
> Could you mention it in feature-removal-schedule.txt?  (People check
> that for warning of upcoming changes that impact existing code.
> They may not notice something elsewhere after they've got it
> working...)

you know, if it makes everyone happier, why don't i just leave that as
it is and move on?  apparently, i have a different understanding of
the word "deprecated" from a number of others here, and it's really
not worth arguing about anymore.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Robert P. J. Day]

On Fri, 31 Aug 2007, Valdis.Kletnieks@vt.edu wrote:

> On Thu, 30 Aug 2007 18:36:48 CDT, Rob Landley said:
>
> > Could you mention it in feature-removal-schedule.txt?  (People check that for
> > warning of upcoming changes that impact existing code.  They may not notice
> > something elsewhere after they've got it working...)
> >
> > (Also, sorting feature-removal-schedule.txt by date would be really nice.  The
> > sucker's gotten huge...)
>
> Maybe it's time we actually start heaving stuff over the side, especially
> that stuff that the removal date has gone by?
>
> What:   dev->power.power_state
> When:   July 2007
> What:   Video4Linux API 1 ioctls and video_decoder.h from Video devices.
> When:   December 2006
> What:   remove EXPORT_SYMBOL(kernel_thread)
> When:   August 2006
> What:   CONFIG_FORCED_INLINING
> When:   June 2006
> What:   eepro100 network driver
> When:   January 2007

some of that has already been discussed and postponed slightly, like
the eepro100 stuff:

http://marc.info/?l=linux-kernel&m=118827478527526&w=2

but some of the rest is definitely overdue.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Thu, 30 Aug 2007 18:36:48 CDT, Rob Landley said:

> Could you mention it in feature-removal-schedule.txt?  (People check that for 
> warning of upcoming changes that impact existing code.  They may not notice
> something elsewhere after they've got it working...)
>
> (Also, sorting feature-removal-schedule.txt by date would be really nice.  The
> sucker's gotten huge...)

Maybe it's time we actually start heaving stuff over the side, especially
that stuff that the removal date has gone by?

What:   dev->power.power_state
When:   July 2007
What:   Video4Linux API 1 ioctls and video_decoder.h from Video devices.
When:   December 2006
What:   remove EXPORT_SYMBOL(kernel_thread)
When:   August 2006
What:   CONFIG_FORCED_INLINING
When:   June 2006
What:   eepro100 network driver
When:   January 2007

5 out of 26 things - close to 20% - is already overdue for nuking.  In some
cases, over a year overdue.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH] docs: ramdisk/initrd/initramfs corrections

[Geert Uytterhoeven]

On Thu, 30 Aug 2007, H. Peter Anvin wrote:
> Rob Landley wrote:
> > On Thursday 30 August 2007 1:28:17 pm Robert P. J. Day wrote:
> > > On Thu, 30 Aug 2007, Randy Dunlap wrote:
> > > 
> > > ...
> > > 
> > > > The old "ramdisk=<ram_size>" has been changed to
> > > > "ramdisk_size=<ram_size>" to make it clearer.  The original
> > > > "ramdisk=<ram_size>" has been kept around for compatibility reasons,
> > > > but it may be removed in the future.
> > > ...
> > > 
> > > i just the other day submitted a patch to remove that backward
> > > compatibility, and the m68k portion of it has already been acked by
> > > geert uytterhoeven.
> > 
> > Could you mention it in feature-removal-schedule.txt?  (People check that
> > for warning of upcoming changes that impact existing code.  They may not
> > notice something elsewhere after they've got it working...)
> > 
> 
> The same objection applies to this as to the previous one.  In that respect,
> an Ack from a maintainer of an almost unused architecture is meaningless
> (sorry, Geert.)

Of course I ack'ed the m68k part, iff the non-arch-specific part was accepted.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds