The documentation for libev (source) says that:
Kqueue deserves special mention, as at the time of this writing, it was broken on all BSDs except NetBSD (usually it doesn't work reliably with anything but sockets and pipes, except on Darwin, where of course it's completely useless).
It also mentions that:
The kqueue syscall is broken in all known versions - most versions support only sockets, many support pipes.
So, what are the limitations of kqueue? Where are these limitations documented? Initial research turned up references to kernel panics on older operating systems (Mac OS X 10.3) and complaints about incorrect/incomplete documentation. I don't know how reliable these sources are.
In particular, if kqueue does work reliably with sockets (AF_UNIX, AF_INET, and AF_INET6) then I don't mind. I am particularly interested in information about the Mac OS X and FreeBSD implementations.
On OS X, you shouldn't have problems with AF_UNIX, AF_INET, and AF_INET6. You will have problems if you want to use it with a PTY on OS X < 10.9, as PTYs are unsupported on those versions. There is some evidence that on OS X 10.9, PTYs are finally supported.
If you try to use the non-file descriptor notifications you will start to run into other limitations (eg AIO is unsupported).
I'm not familiar with FreeBSD's kqueue implementation. Perhaps someone else who is can add some information about it.
kqueue is perfectly working on FreeBSD, at least for networking. I have tested myself networking stuff with up to 180k connected, active sockets. I don't know for AIO .. haven't tested myself.
Related
The traditional way to call the Unix realpath() function has been realpath(pathname, buf) where buf is a user-supplied buffer with room for PATH_MAX bytes. This is problematic since PATH_MAX is unnecessarily big for most filenames and yet can be smaller than the actual OS pathname length limit.
The ability to pass a NULL pointer in place of buf was later added. In this case realpath() will dynamically allocate a buffer of the right size using malloc(). This makes the function easy to use safely. Since NULL support was a later addition, it was not universally implemented and hence portable programs could not rely on it.
POSIX Issue 7, 2018 edition now guarantees NULL support. Endorsement by POSIX would seem to imply that the portability concerns have all but vanished. Are there any Unix systems in active use (e.g. from the last decade) where realpath() does not support giving a NULL buffer?
realpath(path, NULL) works on recent releases of at least the following systems:
Darwin
DragonFly BSD
FreeBSD
Haiku
Linux/glibc
Linux/musl
Minix
NetBSD
OpenBSD
Solaris (OmniOS)
According to the Gnulib documentation, the Gnulib developers last saw this issue on
Mac OS X 10.5 (end of support in 2011),
FreeBSD 6.4 (end of support in 2010),
OpenBSD 4.4 (end of support in 2009),
Solaris 10 (end of support in 2024).
I'm very interested in the Mesh technology and the (new) IEEE Mesh standard 802.11s. I've looked for some Wi-Fi modules which support the standard but it's never mentioned, although the standard was published at the end of 2011.
I also have read about the open802.11s solution (http://open80211s.org/open80211s/), but there are also no Wi-Fi modules mentioned. So I have the following questions:
Does this mean that all Modules support it and you only have to get the correct driver (mac80211)?
I've read about the Linux Kernel which supports the 11s standard. Are there all parts implemented?
Checkout this page drivers for a list of drivers and whether or not they support mesh networking. You can find ath9k, b43, among others that support mesh - but Intel iwlwifi doesn't. From those drivers, you can find corresponding chipsets that are expected to work on that mode.
Note, however, mesh networking currently implemented in the kernel does not necessarily support all features found in the 802.11s standard (now part of 802.11-2012).
Is there any equivalent of IO COmpletion ports on Mac OS X for implementing Asynchronous IO on files....
Thank you....
Unfortunately, no.
kqueue is the mechanism for high-performance asynchronous i/o on OSX and FreeBSD. Like Linux epoll it signals in the opposite end of i/o compared to IOCPs (Solaris, AIX, Windows). kqueue and epoll will signal when it's ok to attempt a read or a write, whereas IOCPs will callback when a read or a write has completed. Many find the signalling mechanism used by epoll and kqueue difficult to understand compared to the IOCP model. So while kqueue and IOCP are both mechanisms for high-performance asynchronous i/o, they are not comparable.
It is possible to implement IOCPs using epoll or kqueue and a thread pool. You can find an example of that in the Wine project.
Correction:
Mac OS X has an implementation of IOCP like functions in Grand Central Dispatch. It uses the GCD thread pool and kqueue APIs internally. Convinience functions are dispatch_read and dispatch_write. Like IOCP the asynchronous I/O functions in GCD signals at the completion of an I/O task, not when the file descriptor is ready like the raw kqueue API.
Beware that GCD APIs are not "fork safe", and cannot be used on both sides of a POSIX fork without an exec. If you do, the function call will never return.
Also beware that kqueue in Mac OS X is rumored to be less performant than kqueue in FreeBSD, so it might be better for development than production. GCD (libdispatch) is Open Source however, and can be used on other platforms as well.
Update Jan 3, 2015:
FreeBSD has GCD from version 8.1. Wine has epoll-based IOCP for Linux. It is therefore possible to use IOCP design to write server code that should run on Windows, Linux, Solaris, AIX, FreeBSD, MacOSX (and iOS, but not Android). This is different from using kqueue and epoll directly, where a Windows server must be restructured to use its IOCPs, and very likely be less performant.
Since you asked for a Windows specific feature for OS X, instead of using kqueue directly you may try libevent. It's a thin wrapper to different AIO mechanisms and it work on both platforms.
Use Kqueue
http://en.wikipedia.org/wiki/Kqueue
This might be a lame question for this site, but here goes.
Can drivers be portable? For instance, could one write a driver for the keyboard-backlight of a mac, and port it to another unix system, maybe Solaris?
or is driver portability a contradiction in terms?
any articles covering this topic would be much appreciated.
Device drivers need to serve two layers of abstraction which makes portability at least hard:
1) Of course the driver needs to be written for a specific device. Your understandable assumption is now that once I implemented a driver according to a proper device specification (data sheet, ...), why shouldn't it run on every computer that needs to access the device.
In comes point
2) Drivers are written to fit into a certain operating system. Each OS has its own means of
a) accessing devices, e.g., the functions for reading/writing I/O ports might be called differently or have different signatures. Furthermore
b), the ultimate goal of a driver is to make the device accessible to the user - be it through a file system interface or network sockets or the X input protocol. For these purposes each OS again comes with its own set of abstractions that the driver needs to fit into.
These are the reasons porting drivers is kind of hard. Nevertheless, there are approaches that try to achieve this, most of the time by wrapping the original driver with glue code that translates the expected driver/OS interface into the target interfaces.
NDISWrapper is a library that allows running Windows WiFi drivers on Linux,
Some guys from Karlsruhe proposed to use device-driver virtual machines,
Several OS frameworks I'm aware of use device-driver wrapper libraries to run Linux/BSD device drivers in their environments. See for instance Genode, L4Re, Minix3.
Yes, they can be.
Assuming a driver is written for the device specifications, the only thing that prevents the driver portability is the underlying operating systems as different operating systems have different architecture and different controls to call and load device drivers.
But there have been known implementations, wherein the underlying OS could be abstracted and a uniform platform could be provided. This can lead to driver portability.
In most modern operating systems like Linux and Windows, is network IO typically accomplished using DMA? This is concerning generic Ethernet controllers; I'm not asking about things that require special drivers (such as many wireless cards, at least in Linux). I imagine the answer is "yes," but I'm interested in any sources (esp. for the Linux kernel), as well as resources providing more general information. Thanks.
I don't know that there really is such a thing as a generic network interface controller, but the nearest thing I know of -- the NE2000 interface specification, implemented by a large number of cheap controllers -- appears to have at least some limited DMA support, and more sophisticated controllers are likely to include more sophisticated features.
The question should be a bit different:
Is typical network adapter have dma
controller on board ?
After finding answer on this question ( i guess in 99.9% it will be yes), you should ask about specific driver for each card. I assume that any decent driver will fully utilize hardware capabilities (i.e DMA support in our case), but question about OS is not relevant, since no OS can force the driver to implement DMA support. A high level OS like Windows and Linux provide a primitives to easier implementation of DMA, but implementing is responsibility of the driver.