Re: File system in battery backed SRAM

From: Gabriele Brugnoni (news_at_dveprojects.com)
Date: 10/17/05

  • Next message: Daniele: "Kuro Box from Japan ?" 
    Date: Mon, 17 Oct 2005 11:33:28 +0200

    Captain Dondo wrote:

    > I have a system with a region of memory that is battery-backed.
    >
    > I'd like to use it as a file system - the idea is to make / read only and
    > put files that need to be modified into the battery backed file system....
    >
    > I've googled about but found nothing that would do this; just some vague
    > references to ramdisks. But then I've found nothing that would let me pin
    > a ramdisk into a specific region in memory and keep it there over reboots.
    >
    > So... Anyone know of any way to do this?
    >
    > Thanks...

    I've developed a little device block driver to do that.
    The way i do it is very simple:

    Look at some block devices, and choose one to use as a skeleton.
    The request function may be something like:

    #include <linux/blk.h>

    // ....

    #define DEVICE_REQUEST do_rh_request

    static void
    do_rh_request( request_queue_t * q )
    {
        mm_segment_t fs;
        u_long start, len, addr, size;

        while ( TRUE )
                    {
                    INIT_REQUEST;

                    minor = MINOR(CURRENT->rq_dev);

                    start = CURRENT->sector << 9;
                    len = CURRENT->current_nr_sectors << 9;
                    size = YOUR_MEMORY_SIZE;

                    if( (start + len) > size )
                            {
                            printk( KERN_ERR DEVICE_NAME ": bad access:
    block=%ld, count=%ld\n",
                            CURRENT->sector,
                            CURRENT->current_nr_sectors);
                            end_request( FALSE );
                            continue;
                            }

                    fs = get_fs();
                    set_fs(KERNEL_DS);
                    addr = YOUR_MEMORY_BASE_ADDRESS + start;

                    if( ( CURRENT->cmd == READ ) )
                            {
                            // READ blocks
                            copy_to_user ( CURRENT->buffer, (char *)addr, len );
                            }
                    else
                            {
                            // WRITE blocks
                            copy_from_user ( (char*)addr, CURRENT->buffer,
    len );
                            }

                    set_fs(fs);
                    end_request( TRUE );
                    }
    }

    This code write or read directly to memory. Each 512 block will be saved in
    the SRAM. You may improve security by reserving one sector area and save in
    that point each sector before modify it.
    At system startup you may check the reserved area, and if it contains a
    stored record you may recover it (the system may be turned-off when writing
    to a sector).

    Then you may format your block device as you do for other disks, for example
    with minix, and mount it.

    Bye, Gabriele

  • Next message: Daniele: "Kuro Box from Japan ?"

    Relevant Pages

    • Re: Forth and CP/M
      ... case you want one of the FIG versions that use block devices and not files ... I plan to work all the way to the sector level independent of the ... simple and the only routines needed (to isolate the disk from the ... provide the low level block buffer routines to access it, ...
      (comp.os.cpm)
    • Re: reading a sector on USB memory stick
      ... I need to write an VB6 application for reading and writing a sector ... on a USB memory stick in a Windows XP system. ... Windows, at least the NT-variants like 2K / XP etc, allow you to open ... many block devices as though they were files, ...
      (microsoft.public.vb.general.discussion)
    • Re: Should a block device enforce block atomicity?
      ... I have a question about block devices and whether they are required to ... there's no block atomicity (i.e. multiple threads can write a single ... WRITE request before other READ/WRITE requests to the same block were ... the same sector in the queue. ...
      (Linux-Kernel)