On Sat 13 Jun 2009 14:59, Wolfgang Denk pondered:
> Dear Russell King,
>
> In message <20090613102642.gb7...@flint.arm.linux.org.uk> you wrote:
> >
> > The other way I've seen people read out crash messages is using a
> > debugger to dump the kernel's log buffer directly. That seems to work
> > a
David Woodhouse wrote:
> On Sun, 2009-06-14 at 10:21 +0200, Marco wrote:
>> Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works
>> in memory. We could simply use /dev/null (there was an error in the
>> submitted kconfig description, my intention was to use /dev/mem). In
>> that c
David Woodhouse wrote:
> On Sun, 2009-06-14 at 10:21 +0200, Marco wrote:
>> Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works
>> in memory. We could simply use /dev/null (there was an error in the
>> submitted kconfig description, my intention was to use /dev/mem). In
>> that c
Jamie Lokier wrote:
> Marco wrote:
>> Simply because the ramdisk was not designed to work in a persistent
>> environment.
>
> One thing with persistent RAM disks is you _really_ want it to be
> robust if the system crashes for any reason while it is being
> modified. The last thing you want is to
Marco wrote:
> Simply because the ramdisk was not designed to work in a persistent
> environment.
One thing with persistent RAM disks is you _really_ want it to be
robust if the system crashes for any reason while it is being
modified. The last thing you want is to reboot, and find various
direct
Marco wrote:
To enable direct
I/O at all times for all regular files requires either that
applications be modified to include the O_DIRECT flag on all file
opens, or that a new filesystem be used that always performs direct
I/O by default."
This could be done as well by just intr
On Sun, 2009-06-14 at 10:21 +0200, Marco wrote:
>
> Mmm...MEM_MAJOR and RAMDISK_MAJOR have the same value and pramfs works
> in memory. We could simply use /dev/null (there was an error in the
> submitted kconfig description, my intention was to use /dev/mem). In
> that case I can use UNNAMED_MAJO
Arnd Bergmann wrote:
> On Saturday 13 June 2009, Marco wrote:
>> void __init mount_root(void)
>> {
>> +#ifdef CONFIG_ROOT_PRAMFS
>> + if (MAJOR(ROOT_DEV) == MEM_MAJOR) {
>> + if (mount_pramfs_root())
>> + return;
>> +
>> + printk(KERN_ERR "V
Sam Ravnborg wrote:
> On Sat, Jun 13, 2009 at 03:23:13PM +0200, Marco wrote:
>> From: Marco Stornelli
>>
>> XIP operations.
>>
>> Signed-off-by: Marco Stornelli
>> ---
>>
>> diff -uprN linux-2.6.30-orig/fs/pramfs/xip.c linux-2.6.30/fs/pramfs/xip.c
>> --- linux-2.6.30-orig/fs/pramfs/xip.c1
Daniel Walker wrote:
> On Sat, 2009-06-13 at 15:22 +0200, Marco wrote:
>> From: Marco Stornelli
>>
>> Makefile and Kconfig.
>>
>> Signed-off-by: Marco Stornelli
>> ---
>>
>
> You should move this patch to 11 of 14, as I think that is the point
> when the filesystem can actually be enabled and fu
Sam Ravnborg wrote:
>> +
>> +config PRAMFS_NOWP
>> +bool "Disable PRAMFS write protection"
>> +depends on PRAMFS
>> +default n
>> +help
>> + Say Y here to disable the write protect feature of PRAMFS.
> n is default so "default n" is not needed.
> If you reverse the logic (and
Arnd Bergmann wrote:
> On Saturday 13 June 2009, Sam Ravnborg wrote:
>>> + union {
>>> + struct {
>>> + /*
>>> + * ptr to row block of 2D block pointer array,
>>> + * file block #'s 0 to (blocksize/4)^2 - 1.
>>> +
Sam Ravnborg wrote:
> On Sat, Jun 13, 2009 at 03:21:48PM +0200, Marco wrote:
>> From: Marco Stornelli
>>
>> +#include
>> +
>> +#ifdef __KERNEL__
>> +#include
>> +#include
>> +#include "pram_fs_sb.h"
>> +#endif
>
> The only reason to have this header file in include/linux/
> is that it is used
Jamie Lokier wrote:
> Marco wrote:
>> Linux traditionally had no support for a persistent, non-volatile
>> RAM-based filesystem, persistent meaning the filesystem survives a
>> system reboot or power cycle intact. The RAM-based filesystems such as
>> tmpfs and ramfs have no actual backing store bu
14 matches
Mail list logo
