I know the signalfd(), eventfd() apis in linux OS.
But, I can't find this api in other OS (SunOS, Aix, HP).
Is it only support in Linux??
Both the signalfd and eventfd APIs are linux specific.
If you're trying to write portable code; then you're better off sticking to the POSIX APIs. Bear in mind that there can be vagaries in the implementations between platforms.
Related
How do I get the benefit of sendfile() (on Linux) and TransmitFile() (on Windows) if I also want to use encryption? Are there any Linux kernel modules or Windows drivers that provide this functionality? The only thing I've found this far is an implementation on FreeBSD by Netflix, but unfortunately that is not my two target platforms.
Google for "Linux KTLS". It's pretty new/experimental though.
I am planning to implement Hiawatha web server on a non-linux platform which is uC/OS-II RTOS.
I need help to port the Linux dependent API's to RTOS platform.
Kindly let me if there are already build libraries that I can use to port Linux on RTOS.
Thanks in Advance
Any code that uses more than just the standard C library will require some porting effort - the extent to which non-standard and OS specific libraries and calls are made will determine the effort required or even the feasibility of such a port.
Most Linux code of any complexity will require a POSIX API and networking code will probably use BSD sockets. Multi-threaded code would likley use pthreads. uC/OS-II has neither of these; it deals with only scheduling, timing, synchronisation and inter-process communication; it is a scheduling kernel, not a full OS in the same sense as Linux - it does not even have a file system - a requirement of most Linux code. Of course adding additional libraries and extensions may provide some or all of what you may need.
Moreover uC/OS-II's simple one-thread-per-priority-level scheduler would make typical Linux multi-threaded code hard to schedule in the manner intended. Most RTOSes (including uC/OS-III) support round-robin/time-sliced scheduling of tasks at the same priority level, but uC/OS-II does not; possibly making it unsuitable for this task.
Something more sophisticated that uC/OS-II may be in order, or perhaps using code more suited to uC/OS-II perhaps. eCos for example is a far more complete RTOS for embedded systems; it is open-source and includes a POSIX API, file-system support and a socket API. It would be far easier to port Linux code to that. Equally there are many lightweight embedded webserver examples that are probably more suited to uC/OS-II and other simple RTOS or even no OS at all. LwIP for example is a TCP/IP stack for small embedded systems for which uC/OS-II ports exist and for which there are web server examples.
The point is that Linux are uC/OS-II are not comparable; one requires < 10Kb of code, the other has a minimal foot-print of about 4Mb! To get Linux code to run on such a system will require you to add a lot of additional code to provide the missing services, and it may not be feasible on your target platform.
[Edit: 08 July 2012]
Have you considered using Micrium's own TCP/IP stack and μC/HTTPs web-server add-on? It is likley to be better integrated to uC/OS-II and provide better performance than non-RTOS specific third-party code.
I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API's to perform tasks such as serial port communication etc... Is there a msdn for linux users or a book covering how linux works internaly if there are apis.
I am very confused.
Well, it's sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it'll be faster to write the application from the begining rather then porting it.
But if it's only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.
hope this help :)
Robert Love has a book on Linux Systems Programming - that will cover this area and Love's books are generally good, so it is worth looking at.
It's not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.
What may be more troublesome is that your Windows application may rely heavily on the Windows executive's windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).
But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.
Good luck in any case.
If the program contains GUI code you must use linux libraries like GTK/XLIB in order to create windows, forms, buttons, etc...
Windows specific functions (like EnterCriticalSection, WaitForSingleObject or _beginthreadex) must be replaced with equivalent linux api functions (a nice tutorial can be found here:
"www.ibm.com/developerworks/systems/library/es-MigratingWin32toLinux.html") or you can use libraries such as w2lpl or wine
A useful library for this kind of problems i've found at http://www.adontec.com/windows-to-linux-port-library.htm
I've had great experiences just using WINE. (https://www.winehq.org/)
You don't really port your app at all. You just make sure it doesnt violate some of the basc constraints of WINE and just run it as is. WINE (though is says it is not) is an emulator of the windows API's and will just do the translation for you. It's pretty complete in its coverage of the API's.
Is the XSI/System V IPC is outdated since we have POSIX IPC mechanisms available in Linux?
What kind of IPC (Sysv/Posix/other) is recommended for newer programs ?
POSIX for basics and dbus for “convoluted” :) things.
CORBA, humm, the only executables depending on it for me are libgnome-2.so and libreoffice, which is a whole lot less than dbus.
Just curious, is it possible to write a multi-platform program that is not writen in Java.
If true, could I do it by compiling two or three different programing languages (for each platform) together so that it would run on different platforms.
See here http://en.wikipedia.org/wiki/Cross-platform
C++ is the traditional cross-platform language. However, there are many other popular choices such as Python.
Python is a multi-platform language, available for all the usual platforms.
Mono offers you the opportunity to write multiplatform applications in C#.
From http://en.wikipedia.org/wiki/Mono_%28software%29:
Mono can be run on Linux, BSD, UNIX,
Mac OS X, Solaris and Windows
operating systems.
Pharo is multiplatform.
It uses the Smalltalk language, which is object-oriented.
There is a free introduction book, Pharo by Example.
Silverlight is multi-platform and can be run out-of-browser.
Perhaps ANSI C. This standard is supported by virtually every known platform and architecture, and you can go just about anywhere with it. However, one must strictly comply with the ANSI C standard as if one doesn't you will almost always introduce some level of platform dependence.
The web, surely! Any web-application can run on any device with a web-browser and an Internet connection. This is probably the "future" of cross-platform development. And your users don't even have to install anything.
There are plenty of non-Java cross-platform languages. C/C++, C# (using Mono), Python, PHP, Perl... Even Visual Basic has a cross platform implementation (http://www.mono-project.com/VisualBasic.NET_support).