linux-kernel - Re: Messaging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AANLkTikaJKhvjVg0wHqrdmj_gQ2BEB9=wcFb_tQMTu5k@mail.gmail.com>
Date:	Mon, 24 Jan 2011 14:32:45 -0500
From:	Sri Ram Vemulpali <sri.ram.gmu06@...il.com>
To:	anil joshi <anilsjoshi123@...il.com>
Cc:	linux-newbie@...r.kernel.org,
	Linux-rt-users <linux-rt-users@...r.kernel.org>,
	linux-kernel-mail <linux-kernel@...r.kernel.org>
Subject: Re: Messaging

Hi Anil,

    Thanks for your response. There are many implementation of
messaging in kernel. I am looking for specific implementation of Linux
kernel.
So, If I am not wrong, from your structures you posted, it seems Linux
is implementing using file system. Lets make this an assumption and
post it to groups.

Please if anyone has idea of messaging implementation, please let us know.

Thanks,
Sri.

On Sun, Jan 23, 2011 at 3:48 PM, anil joshi <anilsjoshi123@...il.com> wrote:
> I would like to share my knowledge with you  if any technical error
> please suggest me
>
> As in Process management
>
> struct thread_info {
>         struct task_struct      *task;          /* main task structure */
>         struct exec_domain      *exec_domain;   /* execution domain */
>         __u32                   flags;          /* low level flags */
>         __u32                   status;         /* thread synchronous flags */
>         __u32                   cpu;            /* current CPU */
>         int                     preempt_count;  /* 0 => preemptable,
>                                                   <0 => BUG */
>         mm_segment_t            addr_limit;
>         struct restart_block    restart_block;
>         void __user             *sysenter_return;
>  #ifdef CONFIG_X86_32
>         unsigned long           previous_esp;   /* ESP of the previous stack in
>                                                    case of nested (IRQ) stacks
>                                                 */
>         __u8                    supervisor_stack[0];
>  #endif
>         int                     uaccess_err;
>  };
>
>
>
>
> struct task_struct  {
>
> -----
> --
> -
> ----
> -----
> }
>
>
> in a similar fashion  File System Management in that VFS
> the four Primary object of VFS are
> (courtesy  by Robert  Love Linux kernel Dev elopement)
> super block object  -> represent mounted file system (contained in
> struct vfsmount)
> i node object -> represent a specific  file
>
> d entry object -> represent directory entry, a single component of a path
> fiie object -> open file as associated with process
>
> Layered approach
> Object of struct mqueue_inode_info layered  on Object of struct inode
> (vfs_inode)
>
> or
>
> Object of struct inode (vfs_inode)  contained in struct mqueue_inode_info
>
>
>
> it contain particular message specific information like
>
> $ ls /dev/mqueue/mymq
> QSIZE:129     NOTIFY:2    SIGNO:0    NOTIFY_PID:8260
>
>
>
> struct mqueue_inode_info {
>        spinlock_t lock;
>        struct inode vfs_inode;
>        wait_queue_head_t wait_q;
>
>        struct msg_msg **messages;
>        struct mq_attr attr;
>
>        struct sigevent notify;
>        struct pid* notify_owner;
>        struct user_struct *user;       /* user who created, for accounting */
>        struct sock *notify_sock;
>        struct sk_buff *notify_cookie;
>
>        /* for tasks waiting for free space and messages, respectively */
>         struct ext_wait_queue e_wait_q[2];
>
>         unsigned long qsize; /* size of queue in memory (sum of all msgs) */
>  };
>
> struct inode  {
>  ----
> ----
> ----
> }
>
>
> we used the generic inode structure as the inode layer does not need
> to know about the  /dev/mqueue/mymq stucture(mqueue_inode_info)
>
> flush
> unlnk
> look up
> mqueue_poll_file,
> mqueue_read_file
> are specific to mqueue inode
> static const struct inode_operations mqueue_dir_inode_operations = {
>        .lookup = simple_lookup,
>        .create = mqueue_create,
>       .unlink = mqueue_unlink,
>  };
>
> static const struct file_operations mqueue_file_operations = {
>        .flush = mqueue_flush_file,
>        .poll = mqueue_poll_file,
>        .read = mqueue_read_file,
>  };
>
> inode->i_fop = &mqueue_file_operations;
> inode->i_op = &mqueue_dir_inode_operations;
>
>
> refer http://bec-systems.com/web/content/view/94/9/
> http://www.kroah.com/log/linux/container_of.html
>
> if u know more regarding mqueue share it
>
> Regards
> Anil.S.Joshi
>



-- 
Regards,
Sri.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/