[PATCH 00/17] pramfs: persistent and protected RAM filesystem

January 06th, 2011 - 07:10 am ET by Marco Stornelli | Report spam
Hi all,

after several reviews is time to submit the code for mainline. Thanks to
CELF to believe and support actively the project and thanks to Tim Bird.

Here the stats:

Documentation/filesystems/pramfs.txt | 179 ++++++
Documentation/filesystems/xip.txt | 2 +
arch/Kconfig | 3 +
arch/x86/Kconfig | 1 +
fs/Kconfig | 8 +-
fs/Makefile | 1 +
fs/pramfs/Kconfig | 72 +++
fs/pramfs/Makefile | 14 +
fs/pramfs/acl.c | 433 +++++++++++++
fs/pramfs/acl.h | 86 +++
fs/pramfs/balloc.c | 147 +++++
fs/pramfs/desctree.c | 181 ++++++
fs/pramfs/desctree.h | 44 ++
fs/pramfs/dir.c | 208 +++++++
fs/pramfs/file.c | 326 ++++++++++
fs/pramfs/inode.c | 848 ++++++++++++++++++++++++++
fs/pramfs/ioctl.c | 121 ++++
fs/pramfs/namei.c | 371 ++++++++++++
fs/pramfs/pram.h | 269 +++++++++
fs/pramfs/pramfs_test.c | 47 ++
fs/pramfs/super.c | 940 +++++++++++++++++++++++++++++
fs/pramfs/symlink.c | 76 +++
fs/pramfs/wprotect.c | 41 ++
fs/pramfs/wprotect.h | 151 +++++
fs/pramfs/xattr.c | 1104 ++++++++++++++++++++++++++++++++++
fs/pramfs/xattr.h | 131 ++++
fs/pramfs/xattr_security.c | 78 +++
fs/pramfs/xattr_trusted.c | 65 ++
fs/pramfs/xattr_user.c | 68 +++
fs/pramfs/xip.c | 83 +++
fs/pramfs/xip.h | 28 +
include/linux/magic.h | 1 +
include/linux/pram_fs.h | 130 ++++
include/linux/pram_fs_sb.h | 45 ++
34 files changed, 6299 insertions(+), 3 deletions(-)


Marco
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
email Follow the discussionReplies 7 repliesReplies Make a reply

Similar topics

Replies

#1 Peter Zijlstra
January 06th, 2011 - 09:10 am ET | Report spam
On Thu, 2011-01-06 at 13:00 +0100, Marco Stornelli wrote:
Hi all,

after several reviews is time to submit the code for mainline. Thanks to
CELF to believe and support actively the project and thanks to Tim Bird.



Tony Luck was also playing with something like this I believe.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#2 Marco Stornelli
January 06th, 2011 - 11:50 am ET | Report spam
Il 06/01/2011 15:03, Peter Zijlstra ha scritto:
On Thu, 2011-01-06 at 13:00 +0100, Marco Stornelli wrote:
Hi all,

after several reviews is time to submit the code for mainline. Thanks to
CELF to believe and support actively the project and thanks to Tim Bird.



Tony Luck was also playing with something like this I believe.




Yes, I know. Even if the approach is different. He is trying to use a
persistent space record-based and with a simple fs interface to store
oops or something like this. The idea here is a little bit different,
i.e. to have a place (a generic piece of memory) to write not sensible
and temporary information with a complete fs structure. However we are
on the same road :)

Marco
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#3 Marco Stornelli
January 06th, 2011 - 12:10 pm ET | Report spam
Il 06/01/2011 17:26, Marco Stornelli ha scritto:
Il 06/01/2011 15:03, Peter Zijlstra ha scritto:
and temporary information with a complete fs structure. However we are




Errata corrige: maybe I used the wrong term, I meant "volatile" instead
of "temporary" information, i.e. I'd like to save this info to re-read
it later but I don't want to store it in flash, a simple log, run-time
information for debug like a flight-recorder or whatever you want.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#4 Luck, Tony
January 06th, 2011 - 01:30 pm ET | Report spam
Errata corrige: maybe I used the wrong term, I meant "volatile" instead
of "temporary" information, i.e. I'd like to save this info to re-read
it later but I don't want to store it in flash, a simple log, run-time
information for debug like a flight-recorder or whatever you want.



I'm puzzled by the use of "a generic piece of memory" to store "persistent"
things (Perhaps this is made clear in the 17 parts of the patch? I haven't
read them yet). On x86 f/w typically clears all of memory on reset ... so
you only get persistence if you use kexec to get from the old kernel to
the new one.

-Tony
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#5 Marco Stornelli
January 06th, 2011 - 01:50 pm ET | Report spam
Il 06/01/2011 19:22, Luck, Tony ha scritto:
Errata corrige: maybe I used the wrong term, I meant "volatile" instead
of "temporary" information, i.e. I'd like to save this info to re-read
it later but I don't want to store it in flash, a simple log, run-time
information for debug like a flight-recorder or whatever you want.



I'm puzzled by the use of "a generic piece of memory" to store "persistent"
things (Perhaps this is made clear in the 17 parts of the patch? I haven't
read them yet). On x86 f/w typically clears all of memory on reset ... so
you only get persistence if you use kexec to get from the old kernel to
the new one.

-Tony




First of all, you can find a lot of information on the web site where
there is an overview and a page with implementation details, benchmark
and so on. With "a generic piece of memory" I mean a generic memory
device directly addressable. Usually this generic device is an NVRAM, so
we have a persistent store. If you haven't got this hw you can use other
devices or the classic RAM, in this case you have a fs persistent only
over reboot. The use of this fs is mainly for embedded systems, fw can
be configured to not clear *all* the memory. Pramfs is indeed supported
by U-Boot, you can see CONFIG_PRAM in the Das U-Boot manual. x86 in this
case can be a "strange" world for this fs, but however if the user wants
it can be used without problems because there aren't neither strict arch
or hw dependency.

Marco
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
Help Create a new topicNext page Replies Make a reply
Search Make your own search