I have been looking at the implementation of POSIX semaphores in
-CURRENT. I noticed that there are several missing pieces, specifically
the man pages and the removal of uthread_sem.c from libc_r.
I suppose the man pages are not critical, but it seems silly to keep
uthread_sem.c in libc_r if
Joe Kelsey wrote:
> I have been looking at the implementation of POSIX semaphores in
> -CURRENT. I noticed that there are several missing pieces, specifically
> the man pages and the removal of uthread_sem.c from libc_r.
>
> I suppose the man pages are not critical, but it seem
Terry Lambert wrote:
Joe Kelsey wrote:
I have been looking at the implementation of POSIX semaphores in
-CURRENT. I noticed that there are several missing pieces, specifically
the man pages and the removal of uthread_sem.c from libc_r.
I suppose the man pages are not critical, but it seems
< said:
> So, is there some mechanism I am missing? Is there a layer between the
> application calling sem_open and the kernel receiving the parameters
> that strips it down to the last component? If there is a higher level
> involved here, why is the low-level ksem_create function worrying a
Garrett Wollman wrote:
< said:
So, is there some mechanism I am missing? Is there a layer between the
application calling sem_open and the kernel receiving the parameters
that strips it down to the last component? If there is a higher level
involved here, why is the low-level ksem_create f
On Fri, Dec 13, 2002 at 08:41:16AM -0800, Joe Kelsey wrote:
> >>portabliity issue as TRU64 (at least) allows arbitrary pathnames as
> >>sempahores, probably storing some sort of marker in the directories (I
> >>get this only from examining the TRU64 online manual pages at
>
>>>http://www.tru64unix
Joe Kelsey wrote:
> >>I have been looking at the implementation of POSIX semaphores in
> >>-CURRENT. I noticed that there are several missing pieces, specifically
> >>the man pages and the removal of uthread_sem.c from libc_r.
[ ... ]
> I am not interested in thre
Joe Kelsey <[EMAIL PROTECTED]> writes:
> Yes, I realize this, but it seems that from my cursory inspection of
> uipc_sem.c that the check for embedded '/' characters is unnecessary and
> much too restrictive according to the posix standard. The standard only
> talks about whether or not the sem
< said:
> So apart from the leading slash character, nothing is mentioned about
> embedded slashes in the semaphore name. What's the right behavior
> for FreeBSD then?
The reason why the standard is written that way was to allow for
RTOS implementations which do not have a filesystem. A quality
Terry Lambert wrote:
Get me the exact file you are concerned about, and I will stare
at it with you. I think, though, that if there is a problem, it's
just that you are catching things in mid-implementation (POSIX
semaphores were supported in the other scope, but not system,
until very recently;
Mike Barcroft wrote:
Sounds like a bug to me. Could you open a PR?
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46239
/Joe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Joe Kelsey wrote:
> /* name must start with a '/' but not contain one. */
> if (*name != '/' || len < 2 || index(name + 1, '/') != NULL) {
> free(ret, M_SEM);
> return (EINVAL);
> }
>
> The comment make
Terry Lambert wrote:
Joe Kelsey wrote:
/* name must start with a '/' but not contain one. */
if (*name != '/' || len < 2 || index(name + 1, '/') != NULL) {
free(ret, M_SEM);
return (EINVAL);
}
The comment
Joe Kelsey wrote:
> > OK, this is a bug. The semantics don't conform to POSIX.
> ...
> > I rather imagine the correct thing to do is to root it in the FS,
> > and, without a leading '/', treat it as relative to the process
> > current directory.
> >
> > Basically, this is not a two line fix... it'
14 matches
Mail list logo
