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

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

[Marco Stornelli]

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 

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

[Peter Zijlstra]

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.

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

[Marco Stornelli]

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

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

[Marco Stornelli]

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.

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

[Luck, Tony]

> 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

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

[Marco Stornelli]

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

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

[Pavel Machek]

> 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.

Actually you probably want to state u-boot compatibility in the commit
message. AFAICT, that is quite good argument _for_ inclusion.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Marco Stornelli]

Hi all,

On 06/01/2011 13:00, 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.
> 
> 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(-)
> 

Can I have a feedback to insert this fs in the linux-next? From this
latest review I received some comments about how to fix some fs problems
on-the-fly without to clean all and restart. My next step will be to
write a simple fsck.pram to allow to fix these situations. However I
think the kernel code it's mature to be inserted in a pre-mainline
container. If I'll receive a positive feedback to my question, I'll
repost the patches to the last version (I updated the fs to be RCU aware
according to the work of Nick).

Marco