Allow RAMFS to be user-selectable, and to be built as a module.
Signed-off-by: Robert P. J. Day <[email protected]>
---
given that the help content for that option suggests it can be built
as a module, it just makes sense to make it selectable and tristate,
unless someone has a compelling argument against it.
diff --git a/fs/Kconfig b/fs/Kconfig
index 58a0650..e79ac86 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -1003,7 +1003,7 @@ config HUGETLB_PAGE
def_bool HUGETLBFS
config RAMFS
- bool
+ tristate "Ramfs support"
default y
---help---
Ramfs is a file system which keeps all files in RAM. It allows
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
>
> Allow RAMFS to be user-selectable, and to be built as a module.
>
> Signed-off-by: Robert P. J. Day <[email protected]>
>
> ---
>
> given that the help content for that option suggests it can be built
> as a module, it just makes sense to make it selectable and tristate,
> unless someone has a compelling argument against it.
How about "check if the kernel builds if you do that"?
On Sat, 25 Aug 2007, Al Viro wrote:
> On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
> >
> > Allow RAMFS to be user-selectable, and to be built as a module.
> >
> > Signed-off-by: Robert P. J. Day <[email protected]>
> >
> > ---
> >
> > given that the help content for that option suggests it can be built
> > as a module, it just makes sense to make it selectable and tristate,
> > unless someone has a compelling argument against it.
>
> How about "check if the kernel builds if you do that"?
i did. i did a simple "make defconfig" and "make", and the kernel
built fine. that patch didn't change the status of RAMFS in any way,
it was still selected as default "y", so why would that patch have
made any difference to the eventual build?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sat, 25 Aug 2007, Al Viro wrote:
> On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
> >
> > Allow RAMFS to be user-selectable, and to be built as a module.
> >
> > Signed-off-by: Robert P. J. Day <[email protected]>
> >
> > ---
> >
> > given that the help content for that option suggests it can be built
> > as a module, it just makes sense to make it selectable and tristate,
> > unless someone has a compelling argument against it.
>
> How about "check if the kernel builds if you do that"?
ah, i see what you mean -- selecting it as a module. apparently,
then, the "help" text telling me "To compile this as a module, choose
M here: the module will be called ramfs." was overly optimistic.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sat, Aug 25, 2007 at 05:40:00PM -0400, Robert P. J. Day wrote:
> On Sat, 25 Aug 2007, Al Viro wrote:
>
> > On Sat, Aug 25, 2007 at 03:40:23PM -0400, Robert P. J. Day wrote:
> > >
> > > Allow RAMFS to be user-selectable, and to be built as a module.
> > >
> > > Signed-off-by: Robert P. J. Day <[email protected]>
> > >
> > > ---
> > >
> > > given that the help content for that option suggests it can be built
> > > as a module, it just makes sense to make it selectable and tristate,
> > > unless someone has a compelling argument against it.
> >
> > How about "check if the kernel builds if you do that"?
>
> i did. i did a simple "make defconfig" and "make", and the kernel
> built fine. that patch didn't change the status of RAMFS in any way,
> it was still selected as default "y", so why would that patch have
> made any difference to the eventual build?
Your patch allows to make it a module. That seems to be the only point of
your patch. So check if it builds when RAMFS is made "m" or "n".