linux-kernel - Re: [PATCH] devtmpfs: support !CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100316190005.GA32555@kroah.com>
Date:	Tue, 16 Mar 2010 12:00:05 -0700
From:	Greg KH <greg@...ah.com>
To:	Peter Korsgaard <jacmet@...site.dk>
Cc:	kay.sievers@...y.org, gregkh@...e.de, linux-kernel@...r.kernel.org,
	linux-embedded@...r.kernel.org
Subject: Re: [PATCH] devtmpfs: support !CONFIG_TMPFS

On Fri, Mar 12, 2010 at 11:25:04AM +0100, Peter Korsgaard wrote:
> Make devtmpfs available on (embedded) configurations without SHMEM/TMPFS,
> using ramfs instead.
> 
> Saves ~15KB.
> 
> Signed-off-by: Peter Korsgaard <jacmet@...site.dk>
> ---
>  drivers/base/Kconfig    |    2 +-
>  drivers/base/devtmpfs.c |    5 +++++
>  fs/ramfs/inode.c        |    2 +-
>  include/linux/ramfs.h   |    2 ++
>  4 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index fd52c48..7e33b16 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -18,7 +18,7 @@ config UEVENT_HELPER_PATH
>  
>  config DEVTMPFS
>  	bool "Maintain a devtmpfs filesystem to mount at /dev"
> -	depends on HOTPLUG && SHMEM && TMPFS
> +	depends on HOTPLUG
>  	help
>  	  This creates a tmpfs filesystem instance early at bootup.
>  	  In this filesystem, the kernel driver core maintains device

With this patch, the Kconfig help text now is incorrect.
Is there a way to explicitly call out in the Kconfig which way devtmpfs
is being created?  How about a multiple selection that chooses either
TMPFS or RAMFS, with the default being TMPFS?

So care to redo this so that people can easily determine what is going
to happen easier than this patch currently causes?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/