Hello.
Sorry if this is a FAQ, but I've searched the archives for this list
(http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only come with references
from 1996!
What is the state of Posix-compliant services (threads, semaphores, timers,
etc.) in the current (v2.2/v2.4) Linux kernels?
Thank you.
PLANET PROJECT will connect millions of people worldwide through the combined
technology of 3Com and the Internet. Find out more and register now at
http://www.planetproject.com
[email protected] wrote:
> Sorry if this is a FAQ, but I've searched the archives for this list
> (http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only come with references
> from 1996!
>
> What is the state of Posix-compliant services (threads, semaphores, timers,
> etc.) in the current (v2.2/v2.4) Linux kernels?
IMHO this is a question better asked of glibc people, not kernel people.
The kernel does its best to facilitate POSIX compliances, but in some
cases the kernel developers have said "POSIX is braindead here!" and
solved a particular problem in a non-POSIX way. [and leaves glibc to
pick up the pieces, and enforce POSIX compliancy]
Also, from what I've seen lately on IRC and lkml, the Single Unix
Specification ("SuS") is generally held in higher regard than POSIX; and
when spec questions arise, kernel developers tend to check SuS before
POSIX (if POSIX is checked at all).
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft | -- Picasso
> [email protected] wrote:
> > Sorry if this is a FAQ, but I've searched the archives for this list
> > (http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only
> come with references
> > from 1996!
> >
> > What is the state of Posix-compliant services (threads,
> semaphores, timers,
> > etc.) in the current (v2.2/v2.4) Linux kernels?
>
> IMHO this is a question better asked of glibc people, not
> kernel people.
>
> The kernel does its best to facilitate POSIX compliances, but in some
> cases the kernel developers have said "POSIX is braindead here!" and
> solved a particular problem in a non-POSIX way. [and leaves glibc to
> pick up the pieces, and enforce POSIX compliancy]
>
> Also, from what I've seen lately on IRC and lkml, the Single Unix
> Specification ("SuS") is generally held in higher regard than
> POSIX; and
> when spec questions arise, kernel developers tend to check SuS before
> POSIX (if POSIX is checked at all).
>
> Jeff
and there's some useful info about libc, threads, etc.,
at the Linux Standard Base CVS (http://www.linuxbase.org/
plus its sf.net project page + CVS links).
~Randy
On Mon, Nov 13, 2000 at 11:00:09AM -0500, Jeff Garzik wrote:
> [email protected] wrote:
> > Sorry if this is a FAQ, but I've searched the archives for this list
> > (http://www.uwsg.iu.edu/hypermail/linux/kernel/) and only come with references
> > from 1996!
> >
> > What is the state of Posix-compliant services (threads, semaphores, timers,
> > etc.) in the current (v2.2/v2.4) Linux kernels?
>
> IMHO this is a question better asked of glibc people, not kernel people.
>
> The kernel does its best to facilitate POSIX compliances,
Well, it does not do its best. There are several areas where kernel should
help, things like POSIX semaphores would be much faster with kernel support,
likewise threads if some things Ulrich stated here a couple of months
ago were done in the kernel, POSIX message queue passing is not doable in
userland without kernel help either (I have a message queue filesystem
kernel patch for this, but it is a 2.5 thing).
Jakub
Jakub Jelinek wrote:
> Well, it does not do its best. There are several areas where kernel should
> help, things like POSIX semaphores would be much faster with kernel support,
> likewise threads if some things Ulrich stated here a couple of months
> ago were done in the kernel,
Would it be reasonable to have these needs documented in a central
location, with patches attached where possible?
Making people other than Linus aware of the technical issues can only
benefit the cause of POSIX compliancy, IMHO...
> POSIX message queue passing is not doable in
> userland without kernel help either (I have a message queue filesystem
> kernel patch for this, but it is a 2.5 thing).
If its small and standalone and doesn't touch existing infrastructure...
Regards,
Jeff
--
Jeff Garzik |
Building 1024 | The chief enemy of creativity is "good" sense
MandrakeSoft | -- Picasso
On Mon, Nov 13, 2000 at 11:00:09AM -0500, Jeff Garzik wrote:
> Also, from what I've seen lately on IRC and lkml, the Single Unix
> Specification ("SuS") is generally held in higher regard than POSIX; and
> when spec questions arise, kernel developers tend to check SuS before
> POSIX (if POSIX is checked at all).
POSIX is the law, but many things are not covered.
SUSv2 is a large collection of random stuff.
The Austin group now prepares a joint revision of POSIX.1 and POSIX.2 and SUSv2.
This is to be the next version of all standards involved.
See also http://www.opengroup.org/austin/
>>>>> "J" == Jeff Garzik <[email protected]> writes:
J> Would it be reasonable to have these needs documented in a
J> central location, with patches attached where possible?
http://kernelbook.sourceforge.net:80/wiki/?LinuxAndPosixCompliance
The lead-in discussion has been snipped and inserted under the more
general topic http://kernelbook.sourceforge.net:80/wiki/?LinuxVsUnix
--
Gary Lawrence Murphy <[email protected]>: office voice/fax: 01 519 4222723
T(!c)Inc Business Innovation through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
"You don't play what you know; you play what you hear." --- Miles Davis
On Mon, Nov 13, 2000 at 11:00:09AM -0500, Jeff Garzik wrote:
> Also, from what I've seen lately on IRC and lkml, the Single Unix
> Specification ("SuS") is generally held in higher regard than POSIX; and
> when spec questions arise, kernel developers tend to check SuS before
> POSIX (if POSIX is checked at all).
One reason for this: You can read SuS online from the net, but
you have to buy your copy of the POSIX standards before you could
look into it.
But POSIX compliance is fortunatly noted in the man pages ;-)
Regards
Ingo Oeser
--
To the systems programmer, users and applications
serve only to provide a test load.
<esc>:x
At Mon, 13 Nov 2000 11:13:19 -0500,
Jakub Jelinek <[email protected]> wrote:
> ago were done in the kernel, POSIX message queue passing is not doable in
> userland without kernel help either (I have a message queue filesystem
> kernel patch for this, but it is a 2.5 thing).
Interesting. Is yours ready for?
(I'm also working with it. I agree it's for 2.5)
Regards,
-- GOTO Masanori
On Sun, Nov 19, 2000 at 07:24:16PM +0900, GOTO Masanori wrote:
> At Mon, 13 Nov 2000 11:13:19 -0500,
> Jakub Jelinek <[email protected]> wrote:
> > ago were done in the kernel, POSIX message queue passing is not doable in
> > userland without kernel help either (I have a message queue filesystem
> > kernel patch for this, but it is a 2.5 thing).
>
> Interesting. Is yours ready for?
> (I'm also working with it. I agree it's for 2.5)
Below is my preliminary version from Sep, 16th if you're interested.
I haven't had time for it since then, so it most probably will not apply
cleanly to current kernel.
Things still to do:
- clean it up
- implement poll on message queues
- handle __SI_RT in architectural copy_siginfo_to_user routines
- test much more than I have done so far
- fix mq_notify - see below
- avoid doing linear searches - see below
Message queues are presented as a new filesystem, mounted usually on
/dev/msg. The objects in that filesystems are fifos with special MQ
semantics.
One can use normal open/read/write on fifos in /dev/msg, which
means mq_open with mq_attr NULL, mq_receive which does not tell the priority
and mq_send with default priority.
Then there are a few ioctls which allow to open with special queue
attributes, send with priority and receive so that you get priority back,
etc.
Things I'm not sure about is mq_notify, because it states the signal should
be sent to the process (ie. I'd think it is tgid, not pid in 2.4.0-test8,
but then I don't know which close/exit should cause the notification
registration to be freed).
Also, I wonder how many pending messages typical message queues have
pending, if not too many, then the current linear search is fine, otherwise
I should put the messages into some heap which would allow O(1) mq_receive.
If you find any races/problems, please let me know.
I've coded mqueue.h public glibc userland header and mqueue.c which has
hacks on top and then basically what could end up in glibc's mq_*.c (after
shm_open.c code for locating mount points is copied in).
Jakub