User space data - Embedded

This is a discussion on User space data - Embedded ; I want to be able to share a dynamic binary tree which is part of a user process in the kernel space. The tree will be used as shared data between user space process and kernel thread. Is this something ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: User space data

  1. User space data

    I want to be able to share a dynamic binary tree which is part of a user
    process in the kernel space. The tree will be used as shared data
    between user space process and kernel thread. Is this something that can
    be accomplished using the mmap() facility? Is there better alternative
    to achieve this? The pointers used in the data structure will be a issue
    for sure.

    The other option would be to add some messages between the user process
    and the kernel and sync up the trees. I am trying to avoid this to avoid
    synchronization issues.

    Thanks,
    Shobha.

  2. Re: User space data

    The "Unix way" would be to make it a file and/or a directory structure
    from user view, doing a driver that offers "open" "read", etc.

    -Michael

  3. Re: User space data

    Michael,

    Are you referring to writing the binary tree to a file? Can you elaborate?

    Thanks,
    Shobha.

    Michael Schnell wrote:
    > The "Unix way" would be to make it a file and/or a directory structure
    > from user view, doing a driver that offers "open" "read", etc.
    >
    > -Michael


  4. Re: User space data

    Shobha wrote:
    > Michael,
    >
    > Are you referring to writing the binary tree to a file?


    Why not ?

    > Can you elaborate?


    The user program can do (e.g.) seek() and read()/write(). These calls
    are transferred 1:1 to the driver. So (AFAIK) a seek to n+1 and read a
    byte does not necessary need to offer the same byte as the second byte
    of two bytes read after seeking to n. Moreover the result of a read can
    change dynamically with any instance.

    So a seek could provide a "tree address" of some kind (e.g. each bit a
    path though the binary tree) and a read could return the leaf data
    (maybe including some kind of linked list data (next/previous leaf) if
    useful).

    Overwriting a leaf would be similar as reading, creating a new leaf
    might use seek(,,end).

    Moreover there are ioctl() calls that can be used for configuration or
    other special purposes.

    -Michael

  5. Re: User space data

    On Sun, 19 Mar 2006 21:09:28 +0100, Michael Schnell wrote:

    >
    > The user program can do (e.g.) seek() and read()/write(). These calls
    > are transferred 1:1 to the driver. So (AFAIK) a seek to n+1 and read a
    > byte does not necessary need to offer the same byte as the second byte
    > of two bytes read after seeking to n. Moreover the result of a read can
    > change dynamically with any instance.
    >
    > So a seek could provide a "tree address" of some kind (e.g. each bit a
    > path though the binary tree) and a read could return the leaf data
    > (maybe including some kind of linked list data (next/previous leaf) if
    > useful).
    >
    > Overwriting a leaf would be similar as reading, creating a new leaf
    > might use seek(,,end).
    >
    > Moreover there are ioctl() calls that can be used for configuration or
    > other special purposes.
    >


    Not quite the same thing, but SNOBOL (a very early string processing
    language, which pioneered what had become regular expressions) had
    user-definable, arbitrary data structures. Binary trees were easily doable...

    In the above scenario, all you really need to provide is a direction to
    the next node/leaf. So a seek for a binary tree has 3 directions:
    parent, left child, right child, for a ternary tree it has 4 directions,
    and for an arbitrary n tree it has up to n+1 directions... Although that
    can be simplified to 4 by using parent, left sibling, right
    sibling, and child.

    There is considerable prior art in implementing these kinds of data
    structures... So a bit of research might yield good results...

    --Yan

    --
    o__
    ,>/'_ o__
    (_)\(_) ,>/'_ o__
    Yan Seiner, PE (_)\(_) ,>/'_ o__
    Certified Personal Trainer (_)\(_) ,>/'_ o__
    Licensed Professional Engineer (_)\(_) ,>/'_
    Who says engineers have to be pencil necked geeks? (_)\(_)


+ Reply to Thread