help with cbioBlkRW - VxWorks

This is a discussion on help with cbioBlkRW - VxWorks ; Hello, I am working with vxWorks 5.5 and executing on a PowerPC Rad750. I am new to these forums, so if I fail to give enough info, please let me know, and I will provide as much as I can. ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: help with cbioBlkRW

  1. help with cbioBlkRW


    Hello, I am working with vxWorks 5.5 and executing on a PowerPC Rad750.
    I am new to these forums, so if I fail to give enough info, please let
    me know, and I will provide as much as I can.

    I am attempting to use this function


    STATUS cbioBlkRW
    (
    CBIO_DEV_ID dev, /* CBIO handle */
    block_t startBlock, /* starting block of transfer */
    block_t numBlocks, /* number of blocks to transfer */
    addr_t buffer, /* address of the memory buffer */
    CBIO_RW rw, /* direction of transfer R/W */
    cookie_t * pCookie /* pointer to cookie */
    )


    I have a CBIO_DEV_ID that I created with the C code


    unsigned int size, n;
    cookie_t *pCookie;
    void *addr;

    /*allocate memory for the ramdisk*/

    size = 0x100000;
    addr = malloc(size);
    ...

    cdev = ramDiskDevCreate(addr, 512, 0, ((0x100000)/512), 0);


    My first question is, how do I get the value startBlock for the call to
    cbioBlkRW.

    My second question is, what is pCookie?

    Any help would be greatly appreciated, thank you.

    --


  2. Re: help with cbioBlkRW

    On Jun 11, 10:54 am, topazdemon
    wrote:
    > Hello, I am working with vxWorks 5.5 and executing on a PowerPC Rad750.
    > I am new to these forums, so if I fail to give enough info, please let
    > me know, and I will provide as much as I can.
    >
    > I am attempting to use this function
    >
    > STATUS cbioBlkRW
    > (
    > CBIO_DEV_ID dev, /* CBIO handle */
    > block_t startBlock, /* starting block of transfer */
    > block_t numBlocks, /* number of blocks to transfer */
    > addr_t buffer, /* address of the memory buffer */
    > CBIO_RW rw, /* direction of transfer R/W */
    > cookie_t * pCookie /* pointer to cookie */
    > )
    >
    > I have a CBIO_DEV_ID that I created with the C code
    >
    > unsigned int size, n;
    > cookie_t *pCookie;
    > void *addr;
    >
    > /*allocate memory for the ramdisk*/
    >
    > size = 0x100000;
    > addr = malloc(size);
    > ..
    >
    > cdev = ramDiskDevCreate(addr, 512, 0, ((0x100000)/512), 0);
    >
    > My first question is, how do I get the value startBlock for the call to
    > cbioBlkRW.
    >
    > My second question is, what is pCookie?
    >
    > Any help would be greatly appreciated, thank you.



    The function you're calling cbioBlkRW looks a lot like ramDiskBlkRW,
    which is supplied as user code with vxWorks 5.5.
    Maybe the comments below from the function header will help.
    It seems as though you are planning to call this cbioBlkRW directly.
    Normally, DosFS would call it.

    /
    ************************************************** *****************************
    *
    * ramDiskBlkRW - Read/Write blocks
    *
    * This routine transfers between a user buffer and the lower layer
    hardware
    * It is optimized for block transfers.
    *
    * dev - the CBIO handle of the device being accessed (from creation
    routine)
    *
    * startBlock - the starting block of the transfer operation
    *
    * numBlocks - the total number of blocks to transfer
    *
    * buffer - address of the memory buffer used for the transfer
    *
    * rw - indicates the direction of transfer up or down (READ/WRITE)
    *
    * *pCookie - pointer to cookie used by upper layer such as dosFsLib(),
    * it should be preserved.
    *
    * RETURNS OK or ERROR and may otherwise set errno.
    *
    */

    Are you trying to implement a DosFS memory disk on top of flash or
    eeprom?
    If so, it's already been done for RAD750 boards.

    HTH,

    GV


  3. Re: help with cbioBlkRW


    > On Jun 11, 10:54 am, topazdemon
    > wrote:
    > > Hello, I am working with vxWorks 5.5 and executing on a PowerPC
    > > Rad750.
    > > I am new to these forums, so if I fail to give enough info, please
    > > let
    > > me know, and I will provide as much as I can.
    > >
    > > I am attempting to use this function
    > >
    > > STATUS cbioBlkRW
    > > (
    > > CBIO_DEV_ID dev, /* CBIO handle */
    > > block_t startBlock, /* starting block of transfer */
    > > block_t numBlocks, /* number of blocks to transfer */
    > > addr_t buffer, /* address of the memory buffer */
    > > CBIO_RW rw, /* direction of transfer R/W */
    > > cookie_t * pCookie /* pointer to cookie */
    > > )
    > >
    > > I have a CBIO_DEV_ID that I created with the C code
    > >
    > > unsigned int size, n;
    > > cookie_t *pCookie;
    > > void *addr;
    > >
    > > /*allocate memory for the ramdisk*/
    > >
    > > size = 0x100000;
    > > addr = malloc(size);
    > > ..
    > >
    > > cdev = ramDiskDevCreate(addr, 512, 0, ((0x100000)/512), 0);
    > >
    > > My first question is, how do I get the value startBlock for the call
    > > to
    > > cbioBlkRW.
    > >
    > > My second question is, what is pCookie?
    > >
    > > Any help would be greatly appreciated, thank you.

    >
    >
    > The function you're calling cbioBlkRW looks a lot like ramDiskBlkRW,
    > which is supplied as user code with vxWorks 5.5.
    > Maybe the comments below from the function header will help.
    > It seems as though you are planning to call this cbioBlkRW directly.
    > Normally, DosFS would call it.
    >
    > /
    > ************************************************** *******************-
    > **********
    > *
    > * ramDiskBlkRW - Read/Write blocks
    > *
    > * This routine transfers between a user buffer and the lower layer
    > hardware
    > * It is optimized for block transfers.
    > *
    > * dev - the CBIO handle of the device being accessed (from creation
    > routine)
    > *
    > * startBlock - the starting block of the transfer operation
    > *
    > * numBlocks - the total number of blocks to transfer
    > *
    > * buffer - address of the memory buffer used for the transfer
    > *
    > * rw - indicates the direction of transfer up or down (READ/WRITE)
    > *
    > * *pCookie - pointer to cookie used by upper layer such as dosFsLib(),
    > * it should be preserved.
    > *
    > * RETURNS OK or ERROR and may otherwise set errno.
    > *
    > */
    >
    > Are you trying to implement a DosFS memory disk on top of flash or
    > eeprom?
    > If so, it's already been done for RAD750 boards.
    >
    > HTH,
    >
    > GV


    I am in fact calling it directly, but I do have a reason, although I
    think my company will not let me talk about that here. It most likely
    appears to be the same call because the underlying device is a ram disk,
    the device being created with cbioRamdiskDevCreate. The test I am
    running is specifically targeted at cbioBlkRW.

    The only thing I don't understand is how to find startBlock for
    cbioBlkRW, even for ramDiskBlkRW. I know I don't seem to know a lot
    about it, I am however, just a lowly intern

    --


  4. Re: help with cbioBlkRW


    > I am in fact calling it directly, but I do have a reason, although I
    > think my company will not let me talk about that here. It most likely
    > appears to be the same call because the underlying device is a ram
    > disk, the device being created with cbioRamdiskDevCreate. The test I
    > am running is specifically targeted at cbioBlkRW.
    >
    > The only thing I don't understand is how to find startBlock for
    > cbioBlkRW, even for ramDiskBlkRW. I know I don't seem to know a lot
    > about it, I am however, just a lowly intern


    Also it should be known that my only interest is in giving cbioBlkRW
    bogus parameters and observing its reaction, however, I do need to have
    a "gold-run" of sorts, in which the routine returns OK

    --


  5. Re: help with cbioBlkRW

    On Jun 12, 8:42 am, topazdemon
    wrote:
    > > On Jun 11, 10:54 am, topazdemon
    > > wrote:
    > > > Hello, I am working with vxWorks 5.5 and executing on a PowerPC
    > > > Rad750.
    > > > I am new to these forums, so if I fail to give enough info, please
    > > > let
    > > > me know, and I will provide as much as I can.

    >
    > > > I am attempting to use this function

    >
    > > > STATUS cbioBlkRW
    > > > (
    > > > CBIO_DEV_ID dev, /* CBIO handle */
    > > > block_t startBlock, /* starting block of transfer */
    > > > block_t numBlocks, /* number of blocks to transfer */
    > > > addr_t buffer, /* address of the memory buffer */
    > > > CBIO_RW rw, /* direction of transfer R/W */
    > > > cookie_t * pCookie /* pointer to cookie */
    > > > )

    >
    > > > I have a CBIO_DEV_ID that I created with the C code

    >
    > > > unsigned int size, n;
    > > > cookie_t *pCookie;
    > > > void *addr;

    >
    > > > /*allocate memory for the ramdisk*/

    >
    > > > size = 0x100000;
    > > > addr = malloc(size);
    > > > ..

    >
    > > > cdev = ramDiskDevCreate(addr, 512, 0, ((0x100000)/512), 0);

    >
    > > > My first question is, how do I get the value startBlock for the call
    > > > to
    > > > cbioBlkRW.

    >
    > > > My second question is, what is pCookie?

    >
    > > > Any help would be greatly appreciated, thank you.

    >
    > > The function you're calling cbioBlkRW looks a lot like ramDiskBlkRW,
    > > which is supplied as user code with vxWorks 5.5.
    > > Maybe the comments below from the function header will help.
    > > It seems as though you are planning to call this cbioBlkRW directly.
    > > Normally, DosFS would call it.

    >
    > > /
    > > ************************************************** *******************-
    > > **********
    > > *
    > > * ramDiskBlkRW - Read/Write blocks
    > > *
    > > * This routine transfers between a user buffer and the lower layer
    > > hardware
    > > * It is optimized for block transfers.
    > > *
    > > * dev - the CBIO handle of the device being accessed (from creation
    > > routine)
    > > *
    > > * startBlock - the starting block of the transfer operation
    > > *
    > > * numBlocks - the total number of blocks to transfer
    > > *
    > > * buffer - address of the memory buffer used for the transfer
    > > *
    > > * rw - indicates the direction of transfer up or down (READ/WRITE)
    > > *
    > > * *pCookie - pointer to cookie used by upper layer such as dosFsLib(),
    > > * it should be preserved.
    > > *
    > > * RETURNS OK or ERROR and may otherwise set errno.
    > > *
    > > */

    >
    > > Are you trying to implement a DosFS memory disk on top of flash or
    > > eeprom?
    > > If so, it's already been done for RAD750 boards.

    >
    > > HTH,

    >
    > > GV

    >
    > I am in fact calling it directly, but I do have a reason, although I
    > think my company will not let me talk about that here. It most likely
    > appears to be the same call because the underlying device is a ram disk,
    > the device being created with cbioRamdiskDevCreate. The test I am
    > running is specifically targeted at cbioBlkRW.
    >
    > The only thing I don't understand is how to find startBlock for
    > cbioBlkRW, even for ramDiskBlkRW. I know I don't seem to know a lot
    > about it, I am however, just a lowly intern


    The startBlock that would be passed in by a file system code (such as
    DosFS) is a function of the how the the media is managed by the fs
    manager.
    There is no right number, but there are wrong numbers.
    A number less than zero is wrong.
    A number greater than the number of blocks on the media is wrong.
    Anything else is valid.

    HTH,
    GV


  6. Re: help with cbioBlkRW


    > On Jun 12, 8:42 am, topazdemon
    > wrote:
    > > > On Jun 11, 10:54 am, topazdemon
    > > >
    > > > wrote:
    > > > > Hello, I am working with vxWorks 5.5 and executing on a PowerPC
    > > > > Rad750.
    > > > > I am new to these forums, so if I fail to give enough info,
    > > > > please
    > > > > let
    > > > > me know, and I will provide as much as I can.

    > >
    > > > > I am attempting to use this function

    > >
    > > > > STATUS cbioBlkRW
    > > > > (
    > > > > CBIO_DEV_ID dev, /* CBIO handle */
    > > > > block_t startBlock, /* starting block of transfer */
    > > > > block_t numBlocks, /* number of blocks to transfer */
    > > > > addr_t buffer, /* address of the memory buffer */
    > > > > CBIO_RW rw, /* direction of transfer R/W */
    > > > > cookie_t * pCookie /* pointer to cookie */
    > > > > )

    > >
    > > > > I have a CBIO_DEV_ID that I created with the C code

    > >
    > > > > unsigned int size, n;
    > > > > cookie_t *pCookie;
    > > > > void *addr;

    > >
    > > > > /*allocate memory for the ramdisk*/

    > >
    > > > > size = 0x100000;
    > > > > addr = malloc(size);
    > > > > ..

    > >
    > > > > cdev = ramDiskDevCreate(addr, 512, 0, ((0x100000)/512), 0);

    > >
    > > > > My first question is, how do I get the value startBlock for the
    > > > > call
    > > > > to
    > > > > cbioBlkRW.

    > >
    > > > > My second question is, what is pCookie?

    > >
    > > > > Any help would be greatly appreciated, thank you.

    > >
    > > > The function you're calling cbioBlkRW looks a lot like
    > > > ramDiskBlkRW,
    > > > which is supplied as user code with vxWorks 5.5.
    > > > Maybe the comments below from the function header will help.
    > > > It seems as though you are planning to call this cbioBlkRW
    > > > directly.
    > > > Normally, DosFS would call it.

    > >
    > > > /
    > > > ************************************************** ***************-
    > > > **********
    > > > *
    > > > * ramDiskBlkRW - Read/Write blocks
    > > > *
    > > > * This routine transfers between a user buffer and the lower layer
    > > > hardware
    > > > * It is optimized for block transfers.
    > > > *
    > > > * dev - the CBIO handle of the device being accessed (from
    > > > creation
    > > > routine)
    > > > *
    > > > * startBlock - the starting block of the transfer operation
    > > > *
    > > > * numBlocks - the total number of blocks to transfer
    > > > *
    > > > * buffer - address of the memory buffer used for the transfer
    > > > *
    > > > * rw - indicates the direction of transfer up or down (READ/WRITE)
    > > > *
    > > > * *pCookie - pointer to cookie used by upper layer such as
    > > > dosFsLib(),
    > > > * it should be preserved.
    > > > *
    > > > * RETURNS OK or ERROR and may otherwise set errno.
    > > > *
    > > > */

    > >
    > > > Are you trying to implement a DosFS memory disk on top of flash or
    > > > eeprom?
    > > > If so, it's already been done for RAD750 boards.

    > >
    > > > HTH,

    > >
    > > > GV

    > >
    > > I am in fact calling it directly, but I do have a reason, although I
    > > think my company will not let me talk about that here. It most
    > > likely
    > > appears to be the same call because the underlying device is a ram
    > > disk,
    > > the device being created with cbioRamdiskDevCreate. The test I am
    > > running is specifically targeted at cbioBlkRW.
    > >
    > > The only thing I don't understand is how to find startBlock for
    > > cbioBlkRW, even for ramDiskBlkRW. I know I don't seem to know a lot
    > > about it, I am however, just a lowly intern

    >
    > The startBlock that would be passed in by a file system code (such as
    > DosFS) is a function of the how the the media is managed by the fs
    > manager.
    > There is no right number, but there are wrong numbers.
    > A number less than zero is wrong.
    > A number greater than the number of blocks on the media is wrong.
    > Anything else is valid.
    >
    > HTH,
    > GV


    Oh I see, so the call will start on the device and any block number 1-
    numberofblocksondevice is ok. Thanks a lot, you have been a big help.
    It's clear to me after I see the answer, imagine that

    --


  7. Re: help with cbioBlkRW

    On Jun 12, 2:20 pm, topazdemon
    wrote:
    > > On Jun 12, 8:42 am, topazdemon
    > > wrote:
    > > > > On Jun 11, 10:54 am, topazdemon
    > > > >
    > > > > wrote:
    > > > > > Hello, I am working with vxWorks 5.5 and executing on a PowerPC
    > > > > > Rad750.
    > > > > > I am new to these forums, so if I fail to give enough info,
    > > > > > please
    > > > > > let
    > > > > > me know, and I will provide as much as I can.

    >
    > > > > > I am attempting to use this function

    >
    > > > > > STATUS cbioBlkRW
    > > > > > (
    > > > > > CBIO_DEV_ID dev, /* CBIO handle */
    > > > > > block_t startBlock, /* starting block of transfer */
    > > > > > block_t numBlocks, /* number of blocks to transfer */
    > > > > > addr_t buffer, /* address of the memory buffer */
    > > > > > CBIO_RW rw, /* direction of transfer R/W */
    > > > > > cookie_t * pCookie /* pointer to cookie */
    > > > > > )

    >
    > > > > > I have a CBIO_DEV_ID that I created with the C code

    >
    > > > > > unsigned int size, n;
    > > > > > cookie_t *pCookie;
    > > > > > void *addr;

    >
    > > > > > /*allocate memory for the ramdisk*/

    >
    > > > > > size = 0x100000;
    > > > > > addr = malloc(size);
    > > > > > ..

    >
    > > > > > cdev = ramDiskDevCreate(addr, 512, 0, ((0x100000)/512), 0);

    >
    > > > > > My first question is, how do I get the value startBlock for the
    > > > > > call
    > > > > > to
    > > > > > cbioBlkRW.

    >
    > > > > > My second question is, what is pCookie?

    >
    > > > > > Any help would be greatly appreciated, thank you.

    >
    > > > > The function you're calling cbioBlkRW looks a lot like
    > > > > ramDiskBlkRW,
    > > > > which is supplied as user code with vxWorks 5.5.
    > > > > Maybe the comments below from the function header will help.
    > > > > It seems as though you are planning to call this cbioBlkRW
    > > > > directly.
    > > > > Normally, DosFS would call it.

    >
    > > > > /
    > > > > ************************************************** ***************-
    > > > > **********
    > > > > *
    > > > > * ramDiskBlkRW - Read/Write blocks
    > > > > *
    > > > > * This routine transfers between a user buffer and the lower layer
    > > > > hardware
    > > > > * It is optimized for block transfers.
    > > > > *
    > > > > * dev - the CBIO handle of the device being accessed (from
    > > > > creation
    > > > > routine)
    > > > > *
    > > > > * startBlock - the starting block of the transfer operation
    > > > > *
    > > > > * numBlocks - the total number of blocks to transfer
    > > > > *
    > > > > * buffer - address of the memory buffer used for the transfer
    > > > > *
    > > > > * rw - indicates the direction of transfer up or down (READ/WRITE)
    > > > > *
    > > > > * *pCookie - pointer to cookie used by upper layer such as
    > > > > dosFsLib(),
    > > > > * it should be preserved.
    > > > > *
    > > > > * RETURNS OK or ERROR and may otherwise set errno.
    > > > > *
    > > > > */

    >
    > > > > Are you trying to implement a DosFS memory disk on top of flash or
    > > > > eeprom?
    > > > > If so, it's already been done for RAD750 boards.

    >
    > > > > HTH,

    >
    > > > > GV

    >
    > > > I am in fact calling it directly, but I do have a reason, although I
    > > > think my company will not let me talk about that here. It most
    > > > likely
    > > > appears to be the same call because the underlying device is a ram
    > > > disk,
    > > > the device being created with cbioRamdiskDevCreate. The test I am
    > > > running is specifically targeted at cbioBlkRW.

    >
    > > > The only thing I don't understand is how to find startBlock for
    > > > cbioBlkRW, even for ramDiskBlkRW. I know I don't seem to know a lot
    > > > about it, I am however, just a lowly intern

    >
    > > The startBlock that would be passed in by a file system code (such as
    > > DosFS) is a function of the how the the media is managed by the fs
    > > manager.
    > > There is no right number, but there are wrong numbers.
    > > A number less than zero is wrong.
    > > A number greater than the number of blocks on the media is wrong.
    > > Anything else is valid.

    >
    > > HTH,
    > > GV

    >
    > Oh I see, so the call will start on the device and any block number 1-
    > numberofblocksondevice is ok. Thanks a lot, you have been a big help.
    > It's clear to me after I see the answer, imagine that


    Actually, valid block numbers start at 0 and range to nblocks-1.
    cbioBlkRW is a generic function which simply calls a device-specific
    function to do the work.
    cbioBlkRW also doesn't check the starting block number or any other
    parameters -- it leaves that to the device specific function.
    For ram disks, the device-specific function is ramDiskBlkRW.
    In your testing you'll probably find that ramDiskBlkRW has a bug.
    It allows a starting block number of nblocks, which is one block
    beyond the media. ;-)
    Since you're looking for bugs, you should also test the case where the
    starting block number is valid but ((startBlockNo + blocksToAccess) >=
    nblocks).

    HTH,
    GV



  8. Re: help with cbioBlkRW


    > On Jun 12, 2:20 pm, topazdemon
    > wrote:
    > > > On Jun 12, 8:42 am, topazdemon
    > > > wrote:
    > > > > > On Jun 11, 10:54 am, topazdemon
    > > > > >
    > > > > > wrote:
    > > > > > > Hello, I am working with vxWorks 5.5 and executing on a
    > > > > > > PowerPC
    > > > > > > Rad750.
    > > > > > > I am new to these forums, so if I fail to give enough info,
    > > > > > > please
    > > > > > > let
    > > > > > > me know, and I will provide as much as I can.

    > >
    > > > > > > I am attempting to use this function

    > >
    > > > > > > STATUS cbioBlkRW
    > > > > > > (
    > > > > > > CBIO_DEV_ID dev, /* CBIO handle */
    > > > > > > block_t startBlock, /* starting block of transfer */
    > > > > > > block_t numBlocks, /* number of blocks to transfer */
    > > > > > > addr_t buffer, /* address of the memory buffer */
    > > > > > > CBIO_RW rw, /* direction of transfer R/W */
    > > > > > > cookie_t * pCookie /* pointer to cookie */
    > > > > > > )

    > >
    > > > > > > I have a CBIO_DEV_ID that I created with the C code

    > >
    > > > > > > unsigned int size, n;
    > > > > > > cookie_t *pCookie;
    > > > > > > void *addr;

    > >
    > > > > > > /*allocate memory for the ramdisk*/

    > >
    > > > > > > size = 0x100000;
    > > > > > > addr = malloc(size);
    > > > > > > ..

    > >
    > > > > > > cdev = ramDiskDevCreate(addr, 512, 0, ((0x100000)/512), 0);

    > >
    > > > > > > My first question is, how do I get the value startBlock for
    > > > > > > the
    > > > > > > call
    > > > > > > to
    > > > > > > cbioBlkRW.

    > >
    > > > > > > My second question is, what is pCookie?

    > >
    > > > > > > Any help would be greatly appreciated, thank you.

    > >
    > > > > > The function you're calling cbioBlkRW looks a lot like
    > > > > > ramDiskBlkRW,
    > > > > > which is supplied as user code with vxWorks 5.5.
    > > > > > Maybe the comments below from the function header will help.
    > > > > > It seems as though you are planning to call this cbioBlkRW
    > > > > > directly.
    > > > > > Normally, DosFS would call it.

    > >
    > > > > > /
    > > > > > ************************************************** ***********-
    > > > > > **********
    > > > > > *
    > > > > > * ramDiskBlkRW - Read/Write blocks
    > > > > > *
    > > > > > * This routine transfers between a user buffer and the lower
    > > > > > layer
    > > > > > hardware
    > > > > > * It is optimized for block transfers.
    > > > > > *
    > > > > > * dev - the CBIO handle of the device being accessed (from
    > > > > > creation
    > > > > > routine)
    > > > > > *
    > > > > > * startBlock - the starting block of the transfer operation
    > > > > > *
    > > > > > * numBlocks - the total number of blocks to transfer
    > > > > > *
    > > > > > * buffer - address of the memory buffer used for the transfer
    > > > > > *
    > > > > > * rw - indicates the direction of transfer up or down
    > > > > > (READ/WRITE)
    > > > > > *
    > > > > > * *pCookie - pointer to cookie used by upper layer such as
    > > > > > dosFsLib(),
    > > > > > * it should be preserved.
    > > > > > *
    > > > > > * RETURNS OK or ERROR and may otherwise set errno.
    > > > > > *
    > > > > > */

    > >
    > > > > > Are you trying to implement a DosFS memory disk on top of
    > > > > > flash or
    > > > > > eeprom?
    > > > > > If so, it's already been done for RAD750 boards.

    > >
    > > > > > HTH,

    > >
    > > > > > GV

    > >
    > > > > I am in fact calling it directly, but I do have a reason,
    > > > > although I
    > > > > think my company will not let me talk about that here. It most
    > > > > likely
    > > > > appears to be the same call because the underlying device is a
    > > > > ram
    > > > > disk,
    > > > > the device being created with cbioRamdiskDevCreate. The test I
    > > > > am
    > > > > running is specifically targeted at cbioBlkRW.

    > >
    > > > > The only thing I don't understand is how to find startBlock for
    > > > > cbioBlkRW, even for ramDiskBlkRW. I know I don't seem to know a
    > > > > lot
    > > > > about it, I am however, just a lowly intern

    > >
    > > > The startBlock that would be passed in by a file system code (such
    > > > as
    > > > DosFS) is a function of the how the the media is managed by the fs
    > > > manager.
    > > > There is no right number, but there are wrong numbers.
    > > > A number less than zero is wrong.
    > > > A number greater than the number of blocks on the media is wrong.
    > > > Anything else is valid.

    > >
    > > > HTH,
    > > > GV

    > >
    > > Oh I see, so the call will start on the device and any block number
    > > 1-
    > > numberofblocksondevice is ok. Thanks a lot, you have been a big
    > > help.
    > > It's clear to me after I see the answer, imagine that

    >
    > Actually, valid block numbers start at 0 and range to nblocks-1.
    > cbioBlkRW is a generic function which simply calls a device-specific
    > function to do the work.
    > cbioBlkRW also doesn't check the starting block number or any other
    > parameters -- it leaves that to the device specific function.
    > For ram disks, the device-specific function is ramDiskBlkRW.
    > In your testing you'll probably find that ramDiskBlkRW has a bug.
    > It allows a starting block number of nblocks, which is one block
    > beyond the media. ;-)
    > Since you're looking for bugs, you should also test the case where the
    > starting block number is valid but ((startBlockNo + blocksToAccess)
    > >nblocks).

    >
    > HTH,
    > GV


    Great! Thank you very much

    RCB

    --


+ Reply to Thread