[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Posix Inter-process comunication on RH 7.1
- To: Linux Israel <linux-il(at-nospam)linux.org.il>
- Subject: Re: Posix Inter-process comunication on RH 7.1
- From: Gold Edward <avieal(at-nospam)inter.net.il>
- Date: Thu, 25 Oct 2001 21:17:30 +0200
- Delivered-To: linux.org.il-linux-il@linux.org.il
- References: <Pine.GSU.4.30_heb2.09.0110250937390.7349-100000@actcom.co.il>
- Sender: linux-il-bounce(at-nospam)cs.huji.ac.il
guy keren wrote:
> On Thu, 25 Oct 2001, Gold Edward wrote:
>
> > Regarding to what Guy Keren wrote:
> >
> > I saw that sigqueue function is documented (xman) on RH 7.1;
> > so maybe it is present on the system -- I will check it tomorow (no,
> > today-it's past 24).
>
> this is because real-time signal queing _is_ supported in the linux
> kernel.
>
> > If it is so, than Guy Keren affirmation "nor posix semaphores in the kernel"
> > it's not
> > holding ground.
>
> what does 'sigqueue' got to do with posix semaphores? its got to do with
> posix real-time queued signals, as far as a web-search yields.
>
Sory, I ment Posix signals (see the late hour on which the msg. was
written) .
sigqueue is distinctely Posix, so I thought that other features would
also be present.
>
> > Can it be that just some of Posix functionality exist on RH
> > 7.1 ?
>
> yes.
>
> > That's not making much sense...
> > How can a systembe Posix compliant but without Posix ipc?
>
> because posix is so fluid. and because it is a moving target. and because
> it has optional parts.
>
> i know this situation is frustrating (heck, i was trying to write portable
> documentation to posix threads a while back, and still get the occasional
> backfire every now and then) and that's why i endorse portability layers.
>
> btw, i wrote what i originaly wrote only after performing a search on
> google - my RH 6.2 system isn't exactly an up-to-date linux system.
>
I have something older (SuSE 6.1 ...).
I have found (hopefully) the answer I needed.
I've attached them - as it seems that they offer the answer for shared
memory problem- in reasonably detail.
About your other message reading:
" for this reason, it is always a good idea not to rely on POSIX
directly,
and rather use some portability libraries - hoping that the writer of
the
library will port it ao all OSes you might need to run your software on
in
the future, or hopeing the library is open source, and that you'll be
able
to do the port to a new platform yourself, if the need arises (its
soemtimes cheaper to do that, then to be unable to port to a new
platform,
in terms of losing contracts)."
I agree in general, BTW I have done porting from DEC-Unix to Irix and it
work almost without any noticeable effort (compile ,link,minor errors
only only) due to
the Posix based ipc mechanisms.
Following the 2 messages that I assume explain the problem.
I will try to change the linux_fsinfo.h file, remake the kernel and see
if it
will solve the problem, but the result will not be available this week
because
the project that is using RH 7.1 is not my main one, and I can do this
only
in spare time & late hours.
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
This is the mail archive of the bug-glibc@gnu.org mailing list for the
glibc project.
Index Nav:
[Date Index] [Subject Index] [Author Index] [Thread
Index]
Message Nav:
[Date Prev] [Date Next]
[Thread Prev] [Thread Next]
SHMFS_SUPER_MAGIC discrepancy,
Linux 2.4.2, glibc 2.2.2
To: bug-glibc at gnu dot org
Subject: SHMFS_SUPER_MAGIC discrepancy, Linux 2.4.2, glibc 2.2.2
From: Jean-Francois Panisset <panisset at discreet dot com>
Date: Sun, 25 Mar 2001 23:01:04 -0500
cc: panisset at discreet dot com
List-Id: Bug reports for the GNU standard C library
<bug-glibc.gnu.org>
I've been running into problems trying to get shm_open() to return
something else than ENOSYS running glibc 2.2.2 and Linux 2.4.2.
In sysdeps/unix/sysv/linux/shm_open.c, I find:
/* Determine where the shmfs is mounted (if at all). */
static void
where_is_shmfs (void)
{
char buf[512];
struct statfs f;
struct mntent resmem;
struct mntent *mp;
FILE *fp;
/* The canonical place is /dev/shm. This is at least what the
documentation tells everybody to do. */
if (__statfs (defaultdir, &f) == 0 && f.f_type == SHMFS_SUPER_MAGIC)
{
/* It is in the normal place. */
mountpoint.dir = (char *) defaultdir;
mountpoint.dirlen = sizeof (defaultdir) - 1;
return;
}
and in sysdeps/unix/sysv/linux/linux_fsinfo.h, I find:
/* Constant that identifies the `shm' filesystem. */
#define SHMFS_SUPER_MAGIC 0x02011994
Unfortunately, in the Linux 2.4.2 source tree, in mm/shmem.c, I find:
#define SHMEM_MAGIC 0x01021994
which is close, but not quite what I want. Tracing through a call
to shm_open(), it does seem that the kernel is returning 0x01021994
as the fs type for the shmfs filesystem, causing shm_open() to fail
and return ENOSYS.
So it seems that in the short term, linux_fsinfo.h should be updated.
In the long term, there should be a way to have a single place where
these magic numbers are defined so that they don't get out of sync.
Of course, I could be completely mistaken on this.
JF
_______________________________________________
Bug-glibc mailing list
Bug-glibc@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-glibc
Follow-Ups:
Re: SHMFS_SUPER_MAGIC discrepancy, Linux 2.4.2, glibc 2.2.2
From: Andreas Jaeger
Index Nav:
[Date Index] [Subject Index] [Author Index] [Thread
Index]
Message Nav:
[Date Prev] [Date Next]
[Thread Prev] [Thread Next]
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
> Re: shm_open doesn't work (fix maybe).
>
> From: Christoph Rohland (cr@sap.com)
> Date: Wed Apr 25 2001 - 02:08:32 EST
>
> Next message: Mike A. Harris: "Re: [PATCH] Single user linux"
> Previous message: Marcus Meissner: "PATCH: trident , pci_enable_device moved"
> In reply to: Jakub Jelinek: "Re: shm_open doesn't work (fix maybe)."
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
>
>
> Hi,
>
> On Tue, 24 Apr 2001, Jakub Jelinek wrote:
> > On Tue, Apr 24, 2001 at 11:46:20AM -0500, Tom Brusehaver (N-Sysdyne
> > Corporation) wrote:
> >>
> >> I have been chasing all around trying to find out why
> >> shm_open always returns ENOSYS. It is implemented
> >> in glibc-2.2.2, and seems the 2.4.3 kernel knows about
> >> shmfs.
> >>
> >> It seems the file linux/mm/shmem.c has:
> >> #define SHMEM_MAGIC 0x01021994
> >>
> >> And the glibc-2.2.2/sysdeps/unix/sysv/linux/linux_fsinfo.h has:
> >> #define SHMFS_SUPER_MAGIC 0x02011994
> >>
> >> Well, which is correct?
> >
> > Update your glibc, 2.2.3pre* matches 2.4.x kernel:
> >
> > 2001-03-03 Ulrich Drepper <drepper@redhat.com>
> >
> > * sysdeps/unix/sysv/linux/linux_fsinfo.h (SHMFS_SUPER_MAGIC):
> > Update for real 2.4 kernels.
>
> Yes, and I apologize to Ulrich that the changed number slipped through
> to the official kernel. My fault.
>
> Greetings
> Christoph
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
=================================================================
To unsubscribe, send mail to linux-il-request@linux.org.il with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail linux-il-request@linux.org.il