unified SysV and Posix mqueues as FS

PATCH In review Peter Waechtler 5 participants 8 messages Oct 27, 2002 – Oct 28, 2002 Documentation

Share & tools

Peter Waechtler

author

2002-10-27 15:25 UTC #0 lore raw

PATCH 1/1 unified SysV and Posix mqueues as FS

I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.

While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:

a) no hassle with locks in case an app crashes
b) guaranteed notification with signals (you can have two apps with different uid that can acces the queue but aren't allowed to send signals)
c) surprisingly, seems a little faster - did not test with NPT

Open issues are:

- notification not tested
- still linear search in queues
- I would really enhance the sys_ipc for handling posix mqueue as well (yes, perhaps it's more ugly - but it fits naturally, you can't specify a priority with a read() - ending up with ioctl())
- funny "locking" in ipc/util.c
- check the ipc ids

Documentation/ioctl-number.txt +1 -0

diff -Nur -X dontdiff vanilla-2.5.44/Documentation/ioctl-number.txt linux-2.5.44/Documentation/ioctl-number.txt
@@ -186,6 +186,7 @@
 0xB0	all	RATIO devices		in development:
 					<mailto:[email protected]>
 0xB1	00-1F	PPPoX			<mailto:[email protected]>
+0xB2	00-1F	linux/mqueue.h
 0xCB	00-1F	CBM serial IEC bus	in development:
 					<mailto:[email protected]>

include/linux/mqueue.h +37 -0

diff -Nur -X dontdiff vanilla-2.5.44/include/linux/mqueue.h linux-2.5.44/include/linux/mqueue.h
@@ -0,0 +1,37 @@
+#ifndef _LINUX_MQUEUE_H
+#define _LINUX_MQUEUE_H
+
+#include <linux/types.h>
+#include <linux/ioctl.h>
+#include <asm/siginfo.h>
+
+struct mq_attr {
+	long	mq_flags;       /* O_NONBLOCK or 0 */
+	long	mq_maxmsg;      /* Maximum number of messages in the queue */
+	long	mq_msgsize;     /* Maximum size of one message in bytes */
+	long	mq_curmsgs;     /* Current number of messages in the queue */
+	long	__pad[2];
+};
+
+struct mq_open {
+	char            *mq_name;       /* pathname */
+	int             mq_oflag;       /* flags */
+	mode_t          mq_mode;        /* mode */
+	struct mq_attr  mq_attr;        /* attributes */
+};
+
+struct mq_sndrcv {
+	size_t          mq_len;         /* message length */
+	long            mq_type;        /* message type */
+	char            *mq_buf;        /* message buffer */
+};
+
+#define MQ_OPEN                _IOW(0xB2, 0, struct mq_open)
+#define MQ_GETATTR     _IOR(0xB2, 1, struct mq_attr)
+#define MQ_SEND                _IOW(0xB2, 2, struct mq_sndrcv)
+#define MQ_RECEIVE     _IOWR(0xB2, 3, struct mq_sndrcv)
+#define MQ_NOTIFY      _IOW(0xB2, 4, struct sigevent)
+
+#define MQ_DEFAULT_TYPE        0x7FFFFFFE
+
+#endif /* _LINUX_MQUEUE_H */

include/linux/msg.h +68 ~~-12~~

114 lines not on this page · raw message

ipc/msg.c +949 ~~-218~~

1,366 lines not on this page · raw message

Jeff Garzik

2002-10-27 15:41 UTC #1 lore raw

Quoted 16 lines · Peter Waechtler

I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.
While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:
a) no hassle with locks in case an app crashes
b) guaranteed notification with signals (you can have two apps with different uid that can acces the queue but aren't allowed to send signals)
c) surprisingly, seems a little faster - did not test with NPT
Open issues are:

Quoted 10 lines

- notification not tested
- still linear search in queues
- I would really enhance the sys_ipc for handling posix mqueue as well (yes, perhaps it's more ugly - but it fits naturally, you can't specify a priority with a read() - ending up with ioctl())
- funny "locking" in ipc/util.c
- check the ipc ids

I don't comment on the overall concept of the patch itself, it's not my area of expertise and it's too early in the morning to think about it ;-)

However, there are three issues to consider in the meantime:
* Documentation/CodingStyle problems. You need to use standard one-tab-for-indentation formatting, just like the code around what you are adding/modifying.
* There is weird text translation in the patch (short example follows). It may be better if you use mutt and vi to include your patch directly, without word wrapping, if attachments are getting mangled.

- msq =3D msg_lock(msqid);
- err =3D -EIDRM;
- if(msq=3D=3DNULL)
- goto out_free;
- ss_del(&s);
- =

* Linus probably won't see your email, he has threatened to flush his entire inbox when he returns from his trip ;-)

Regards,

Jeff

Alexander Viro

2002-10-27 15:47 UTC #2 lore raw

In reply to Peter Waechtler

Quoted 6 lines · Peter Waechtler

I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.
While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:

*thud*

ioctls on _directories_, of all things?

H. Peter Anvin

2002-10-27 19:43 UTC #3 lore raw

Followup to:  <[email protected]>
By author:    Alexander Viro <[email protected]>
In newsgroup: linux.dev.kernel

Quoted 7 lines · Peter Waechtler

Quoted 5 lines
I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.

Quoted 7 lines

Quoted 2 lines
While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:
*thud*
ioctls on _directories_, of all things?

Yup. There are plenty of them already.

-hpa

Signature · 3 lines

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

Peter Waechtler

author

2002-10-27 21:53 UTC #4 lore raw

In reply to Alexander Viro

Quoted 7 lines · Alexander Viro

Quoted 4 lines · Peter Waechtler
I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.

Quoted 6 lines

Quoted 2 lines
While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:
*thud*
ioctls on _directories_, of all things?

Parden? Where are directories used?
create a file, give it a size, mmap it and serialize access to it with locks. That's all.

Alexander Viro

2002-10-28 01:48 UTC #5 lore raw

Quoted 11 lines · Peter Waechtler

Quoted 10 lines · Alexander Viro
Quoted 6 lines · Peter Waechtler
I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.
While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:

Quoted 7 lines

Quoted 3 lines
*thud*
ioctls on _directories_, of all things?
Parden? Where are directories used?
create a file, give it a size, mmap it and serialize access to it with locks. That's all.

Check your file_operations for root directory.

Peter Waechtler

author

2002-10-28 10:35 UTC #6 lore raw

Quoted 16 lines · Alexander Viro

Quoted 13 lines · Peter Waechtler
Quoted 12 lines · Alexander Viro
Quoted 6 lines · Peter Waechtler
I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.
While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:
*thud*

Quoted 7 lines

Quoted 5 lines
Quoted 1 line
ioctls on _directories_, of all things?
Parden? Where are directories used?
create a file, give it a size, mmap it and serialize access to it with locks. That's all.
Check your file_operations for root directory.

Umh, misunderstanding: I thought you commented on the Irix part. And it's not my patch, it's Jakub Jelineks patch I applied against current 2.5

I don't even see an advantage on having them as filesystem - I just think that the SysV and Posix mqueues should share most of the code.

Bill Davidsen

2002-10-28 22:15 UTC #7 lore raw

In reply to Peter Waechtler

Quoted 4 lines · Peter Waechtler

I applied the patch from Jakub against 2.5.44
There are still open issues but it's important to get this in before feature freeze.

Quoted 8 lines

While you can implement Posix mqueues in userland (Irix is doing this with fcntl(fd,F_SETLKW,) and shmem) a kernel implementation has some advantages:
a) no hassle with locks in case an app crashes
b) guaranteed notification with signals (you can have two apps with different uid that can acces the queue but aren't allowed to send signals)
c) surprisingly, seems a little faster - did not test with NPT

Surprises me, But I don't question it's possible. As long as it doesn't make the SysV stuff slower, 2.5 in general has more latency than 2.4, so I am sensitive to that.

Quoted 10 lines

Open issues are:
- notification not tested
- still linear search in queues
- I would really enhance the sys_ipc for handling posix mqueue as well (yes, perhaps it's more ugly - but it fits naturally, you can't specify a priority with a read() - ending up with ioctl())
- funny "locking" in ipc/util.c
- check the ipc ids

Signature · 3 lines

bill davidsen <[email protected]>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Documentation/ioctl-number.txt +1 -0

diff -Nur -X dontdiff vanilla-2.5.44/Documentation/ioctl-number.txt linux-2.5.44/Documentation/ioctl-number.txt
@@ -186,6 +186,7 @@
 0xB0	all	RATIO devices		in development:
 					<mailto:[email protected]>
 0xB1	00-1F	PPPoX			<mailto:[email protected]>
+0xB2	00-1F	linux/mqueue.h
 0xCB	00-1F	CBM serial IEC bus	in development:
 					<mailto:[email protected]>

include/linux/mqueue.h +37 -0

diff -Nur -X dontdiff vanilla-2.5.44/include/linux/mqueue.h linux-2.5.44/include/linux/mqueue.h
@@ -0,0 +1,37 @@
+#ifndef _LINUX_MQUEUE_H
+#define _LINUX_MQUEUE_H
+
+#include <linux/types.h>
+#include <linux/ioctl.h>
+#include <asm/siginfo.h>
+
+struct mq_attr {
+	long	mq_flags;       /* O_NONBLOCK or 0 */
+	long	mq_maxmsg;      /* Maximum number of messages in the queue */
+	long	mq_msgsize;     /* Maximum size of one message in bytes */
+	long	mq_curmsgs;     /* Current number of messages in the queue */
+	long	__pad[2];
+};
+
+struct mq_open {
+	char            *mq_name;       /* pathname */
+	int             mq_oflag;       /* flags */
+	mode_t          mq_mode;        /* mode */
+	struct mq_attr  mq_attr;        /* attributes */
+};
+
+struct mq_sndrcv {
+	size_t          mq_len;         /* message length */
+	long            mq_type;        /* message type */
+	char            *mq_buf;        /* message buffer */
+};
+
+#define MQ_OPEN                _IOW(0xB2, 0, struct mq_open)
+#define MQ_GETATTR     _IOR(0xB2, 1, struct mq_attr)
+#define MQ_SEND                _IOW(0xB2, 2, struct mq_sndrcv)
+#define MQ_RECEIVE     _IOWR(0xB2, 3, struct mq_sndrcv)
+#define MQ_NOTIFY      _IOW(0xB2, 4, struct sigevent)
+
+#define MQ_DEFAULT_TYPE        0x7FFFFFFE
+
+#endif /* _LINUX_MQUEUE_H */

include/linux/msg.h +68 ~~-12~~

114 lines not on this page · raw message

ipc/msg.c +949 ~~-218~~

1,366 lines not on this page · raw message