Date: Wed, 17 Feb 1999 03:01:18 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: peter.jeremy@AUSS2.ALCATEL.COM.AU (Peter Jeremy) Cc: hackers@FreeBSD.ORG Subject: Re: Semaphore handling Message-ID: <199902170301.UAA18215@usr08.primenet.com> In-Reply-To: <99Feb17.121602est.40408@border.alcanet.com.au> from "Peter Jeremy" at Feb 17, 99 12:26:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 1) What are the rules regarding the use of gcc extensions in the > kernel? (This doesn't appear to be mentioned in style(9)). > Background: semop() currently uses the macro MAX_SOPS to specify > the maximum number of sem_op's it can process at one time. IMHO, > this is wrong, it should be using SEMOPM (via seminfo.semopm). The > problem is that this value is needed to allocate a local buffer > into which to copy the user's sem_ops. Currently this is an auto > variable: > struct sembuf sops[MAX_SOPS]; > The simplest fix is to change this to: > struct sembuf sops[seminfo.semopm]; > but this is a gcc extension. This is bad. There are only two places where this is currently used. We do use linker sets, but those are more properly an "ld" extension. The linker set code can "go away" when support is added for multiple ELF section loading for binaries. More properly, the sections should be agregated, even if from seperate objects. There was an _init/.init discussion a while back, and the place to deal with this is a functional interface into the ELF image's ".init" section so that it is called when the object is instanced (in this case, the kernel being instanced by the kernel loader). The general consensus had been "make it compilable with a K & R compiler" until ANSI C was adopted a while ago. The CSRG code was pure K & R safe. Core will say "ANSI C, with prototypes". > The alternative is malloc() - either > allocate/free the local buffer on each semop() call [which is slow] > or allocate a single buffer and reuse it [which means more work for > whoever puts fine-grained SMP locks into the semaphore handling]. Fine grained SMP locks don't have to deal with POSIX semaphores, since they aren't SMP safe (use mutexes for SMP safety). The SVR4 semaphores are better implemented as mutexes, internally. My personal preference would be for realloc-type bechaviour as a result of sysctl modification, and a static pointer to the buffer, instead of an auto variable. Alternately, let it be slower, since it's a deprecated interface (John Dyson and other consumers of the interface might not like that, though). You also might want to talk to Amancio Hasty, since he was talking about implementing real semaphores and mutexes for pthreads to avoid the spinlock overhead in kaffe in the user space code. He found a couple of very interesting papers in the literature, one of which I think is probably the best implementation I have seen, and is SMP safe. > 2) TOG is unclear as to the type for sem_num in struct sembuf. In > semop(2) it's defined as `short', in sys/sem.h it's defined as > `unsigned short'. We (and DEC) currently use ushort (Linux and > Solaris use short). Which is the preferable type? [ ... ] > 3) Neither FreeBSD nor TOG not clearly define semadj behaviour. The > wording is (roughly) sem_op is subtracted from semadj in semop() > and semadj is added to semval in exit(). There does not appear to > be a clear definition for behaviour when a process exits for the > following cases: Solaris and UnixWare are definitive. This is a System V interface, and actual System V behaviour is authoritative. You may want to dig up a copy of the SVID III, if you can; it is probably better at rigorous definition than the Go Solo 2 Single UNIX Specification, since the latter is a compromise document meant to cover existing vender implementations, while the former is a documentation of System V behaviour. Note: The use of the ushort in sem.h is (potentially) intended to be a compatability bridge for a common underlying implementation; see semaphore.h on the CDROM, as well. Another possibile authority is the NIST/PCTS code, which tests POSIX Conformance, and *may* test this boundary (been a long time since I ran it). You can download it from the NIST archive (it's searchable using Altavista, if you don't know where it is). SCO has put out their packaging system. They may be willing to let out the SVID III compliance test, if someone hinted about maybe "standardizing on an ABI". If so, you will need TET to run it, and TET fails to build on FreeBSD, and is not permitted to be modified for conformance testing. If I remember correctly, it was because of a problem in the shell, which may have been subsequently fixed. This isn't an issue for this particular test, but it is an issue if you go and try to make a port of the thing. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902170301.UAA18215>