Date: Tue, 9 Feb 1999 22:46:57 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kuku@gilberto.physik.RWTH-Aachen.DE (Christoph Kukulies) Cc: hackers@FreeBSD.ORG Subject: Re: portability of shm, mmap, pipes and socket IPC Message-ID: <199902092246.PAA10658@usr02.primenet.com> In-Reply-To: <199902072122.WAA15102@gilberto.physik.RWTH-Aachen.DE> from "Christoph Kukulies" at Feb 7, 99 10:22:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Does anyone have experience with portability of common > IPC mechanisms between Linux 2.x and FreeBSD? > > I'm trying to estimate the risk of a porting project from > Linux to FreeBSD. > What peculiarities are there? Incompatibilities between the > two OSs WRT to 'clean' implementation of these disciplines? > > sockets - feature set compatible? A common error in Linux programming is to not bzero sockaddr_in contents, and to just set two fields and use them, trusting the kernel to ignore the supposedly "insignificant" uninitialized data. These programs will not function when compiled on FreeBSD (or when using IPv6 on other patforms). FreeBSD does not select writeable on sockets. Sockets can be written if there are mbuf's available, and mbuf's can become unavailable asynchronously between the select coming true and the subsequent write. Select for write is generally an artifact of porting a winsock program to a UNIX system. FreeBSD fails to support fcntl's on sockets: F_SETOWN, F_GETOWN, F_GETLK, F_SETLK, F_SETLKW. This is due to the use of struct fileops, since sockets are not backed by true vnode objects. > pipes - ? named pipes? FreeBSD pipes are bidirectional, since they are implemented with the AF_UNIX socket code. FreeBSD fails to support fcntl's on pipes: F_SETOWN, F_GETOWN, F_GETLK, F_SETLK, F_SETLKW. This is due to the use of struct fileops, since pipes are not backed by true vnode objects. > mmap - stable? limitations? FreeBSD has a unified vm and buffer cache. In theory, you do not need to call msync(2), ever, on such a system. However, there are a number of coherency bugs that make it necessary to call it (mostly in INN-type situations, where the file is being extended while it is mapped). Linux is supposedly a unified VM and buffer cache as well; but Linux also requires msync(2) for correct coherency. INN appears to run without this, but data is not written back to the backing file as it should be. > shmxxx - SYSV compatibility? FreeBSD shared memory segments are limited in size at kernel compilation time; this can be overriden with kernel configuration options. The overall size of the shared memory segment is limited to that which can fit in the kernels virtual address space; this artificially restricts the maximum size. FreeBSD semaphores are inadequately resource tracked in _exit(). 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?199902092246.PAA10658>