where are normal ioctl calls handled? - VxWorks

This is a discussion on where are normal ioctl calls handled? - VxWorks ; Hello everybody, I have a problem concerning vxWorks 5.5 vs. vxWorks 6.x. for a CPU board I use a self written Flash MTD driver which is registered under 5.5 with rawFsDevCreate(). When I do ioctl() on the created "/flash_raw:0" I ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: where are normal ioctl calls handled?

  1. where are normal ioctl calls handled?


    Hello everybody,

    I have a problem concerning vxWorks 5.5 vs. vxWorks 6.x. for a CPU board
    I use a self written Flash MTD driver which is registered under 5.5 with
    rawFsDevCreate(). When I do ioctl() on the created "/flash_raw:0" I see
    with debug prints that the ioctl function in my driver are called.

    When I do the same in vxWorks 6.2 I have to use a xbdBlkDevCreate call
    first, I can then read and write to my Flash, but my ioctl calls get
    stuck somewhere in the xbd Layer or rawFs. I make

    fd = open("/flash_raw:0", O_RDWR)
    ....
    ret = ioctl(fd, , &arg)

    in kernel space.

    can somebody point me in the right direction ? I tried grepping in the
    sources already.

    Thanks!


  2. Re: where are normal ioctl calls handled?

    In article <4426D442.8070409@hotmail.com>
    Thomas Sch. wrote:

    [ code that works in 5.5 ]

    >When I do the same in vxWorks 6.2 I have to use a xbdBlkDevCreate call
    >first, I can then read and write to my Flash, but my ioctl calls get
    >stuck somewhere in the xbd Layer or rawFs. I make
    >
    >fd = open("/flash_raw:0", O_RDWR)
    >...
    >ret = ioctl(fd, , &arg)
    >
    >in kernel space.
    >
    >can somebody point me in the right direction?


    If the ioctl is not handled at a higher level (e.g., in rawFsIoctl,
    assuming there is a rawfs on top of the XBD) the rawFsIoctl
    function should pass it down to the driver after the usual
    XBD_TEST:

    ...
    default:
    error = (xbdIoctl
    (pRawFd->pRawFdVd->rawVdXbd, function,
    (void *)arg));

    (where xbdIoctl just maps the device_t and calls your driver).
    Thus, aside from using the new XBD system, this should work the
    same as in 5.5.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.

+ Reply to Thread