i've downloaded "openjdk-6-src-b23-05_jul_2011" to have a look at the native implementations for the methods in sun.misc.Unsafe. e.g. compareAndSwapInt(...) but i am not able find anything in the downloaded sources of openjdk. i want to get an idea how these methods look like (i was interested in the atomic stuff the jdk provides).
could anybody point me to the right location(s)?
$ ls jdk/src/
linux share solaris windows
$ ls hotspot/src/os/
linux posix solaris windows
any help appreciated
marcel
Implementation of unsafe methods itself is not OS-specific, therefore it can be found in hotspot/src/share/vm/prims/unsafe.cpp. It delegates to hotspot/src/share/vm/runtime/atomic.cpp, which includes OS and CPU specific files, such as hotspot/src/os_cpu/windows_x86/atomic_windows_x86.inline.hpp.
Gcc atomic builtins as provided like java
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
But problem is there is no standard, as you move to solaris, you will need something else. So you have to use different system call as you change your platform.
Related
I want to use Inetsim and that too, only on windows. Can I use it with help of cygwin?
Inetsim is a linux tool for simulating internet services.
I have this same question.
The following excerpt is the requirements for INetSim:
For using INetSim you need a system which meets the following
prerequisites:
POSIX compatible and System V IPC capable operating system (e.g. Linux)
Perl version 5.006 or more recent
Perl library Net::Server (available from http://metacpan.org/pod/Net::Server)
Perl library Net::DNS (available from http://metacpan.org/pod/Net::DNS)
Perl library IPC::Shareable (available from http://metacpan.org/pod/IPC::Shareable)
Perl library Digest::SHA (available from http://metacpan.org/pod/Digest::SHA)
Perl library IO::Socket::SSL (available from http://metacpan.org/pod/IO::Socket::SSL)
additionally, for IP-based connection redirection (only supported on Linux platforms with kernel support for packet queueing): Perl library Perlipq (available from https://metacpan.org/release/perlipq)
While Cygwin strives to be POSIX compatible, there is the question of what System V is and whether or not it's supported. This unhelpful message from the mailing list for the Cygwin project directs us to this entry from the user guide. Reading into the post suggests that System V is for IPC shared memory and message queues. Thankfully, the following excerpt from the guide suggests that running cygserver will provide the necessary services for System V to function:
-m, --no-sharedmem
Don't start XSI IPC Shared Memory support. If you don't need XSI IPC
Shared Memory support, you can switch it off here. Configuration file
option: kern.srv.sharedmem
-q, --no-msgqueues
Don't start XSI IPC Message Queues. Configuration file option:
kern.srv.msgqueues
Cygwin version 2.844 is current as of this post, and it provides Perl 5.14.4-1, which satisfies the second requirement.
The 3rd to 7th bullets surround particular perl libraries and are left as an exercise to the reader.
The final bullet, may be the nail in the coffin, however, as I can find no evidence that Perlipq is available for Cygwin (note: this requires kernel support as well, which can easily become too big of a problem for Cygwin to bother with).
Unless something changes, I believe the answer to your question is: No, INetSim cannot be used with cygwin.
I'm compiling my code on a server that has OpenMPI, but I need to know which version I'm on so I can read the proper documentation. Is there a constant in <mpi.h> that I can print to display my current version?
As explained in this tutorial, you may also check the MPI version running the command:
mpiexec --version
or
mpirun --version
in your terminal.
With OpenMPI, the easiest thing to do is to run ompi_info; the first few lines will give you the information you want. In your own code, if you don't mind something OpenMPI specific, you can look at use OMPI_MAJOR_VERSION, OMPI_MINOR_VERSION, and OMPI_RELEASE_VERSION in mpi.h. That obviously won't work with MPICH2 or other MPI implementations.
More standardly, as part of MPI-3, there is a standard MPI routine called MPI_Get_library_version which gives you detailed library information at run time. This is small enough and useful enough that newer versions of MPI implementations will have this very quickly - for instance it's in the OpenMPI 1.7 development trunk - but it doesn't really help you today.
I am not familier with OpenMPI but MPI has a function MPI_Get_Version, please check your mpi.h for similar functions.
You can also get the version of OpenMPI that the compiler wrapper (e.g. mpicxx/mpic++/mpicc/mpifort) comes from:
mpicxx --showme:version
This can be useful if (for any reason) you have different versions of MPI compiler wrapper and executor.
(Just mpicxx --showme will additionally show you where MPI is installed and which compiler flags uses, see the manual for more.)
NanoBSD is a script that makes light, small and in-memory FreeBSD copy. It is useful in embedded systems. Is there something similar to NanoBSD in Linux? Specially a feature like Everything is read-only at run-time as it mentioned here .
A lot of toolchain / system build systems build Linux root filesystems which are designed to run completely out of a ramdisc (rootfs / tmpfs). This means that everything is read/write at runtime, but it does not persist across reboots (a persistent FS can of course, be mounted as a non-root FS).
The most well known of these is Busybox (with or without uclibc), which ships with various scripts to build very small-footprint Linux-based embedded systems (root FS is typically a few Mb only; just add a kernel). Busybox/Linux is not the same as GNU/Linux, but it is fairly similar - most things are simpler or have fewer options; some features are entirely absent or can be disabled at compile-time.
Linux is NOT an Operating system like FreeBSD, rather it is a kernel. You can choose to layer either GNU C library and tools (which I think all major general-purpose distributions do) or something else - which is mostly used for smaller systems, including uclibc, Android etc.
There are literally hundreds of toolchains, build environments and embedded distros of Linux, some only a couple of megabytes in size. Many also support some or many of the different processors Linux runs on (i386 and friends, ARM, Power, ...).
To get you started a couple of projects I find interesting: OpenWrt and OpenEmbedded, and lpclinux, Linux for NXP LPC3xxx ARM processors but there are really hundreds of them.
Some other resources
A very good source that (also) touches a number of issues specific to embedded systems is Linux from scratch. And this pdf gives some insight in the different available filesystems for an embedded Linux system.
i would take a look at TinyCore-Linux.
which isn't really ro but nearly the same Concept and i think there is also a was to get the OS/Binary Part ro were the config part is writeable.
The question is how to execute aout-format binary (I mean old format which for example used on FreeBSD before it has migrated to ELF) on Linux system. Is there a possibility to do so without extra coding (is there some existing solution)? Probably it should be in form of kernel module or patch for the Linux kernel. Another solution could be user-space launcher (may be even run-time linker). I have searched for something similar but was unable to found something. I have not yet checked difference in system calls interfaces, if you have some comments about that, you are welcome to provide them.
P.S. I know that writing user-space launcher for aout static binary is quite trivial but the question is about some existing solution.
Check for CONFIG_BINFMT_AOUT in your kernel config.
If your kernel has /proc/config.gz:
zgrep CONFIG_BINFMT_AOUT /proc/config.gz
On Ubuntu and the like:
grep CONFIG_BINFMT_AOUT /boot/config-$(uname -r)
Kernel option was CONFIG_BINFMT_AOUT, not sure if it's still around or necessary.
As all Linux distributions use the same kernel, is there any difference between their executable binary files?
If yes, what are the main differences? Or does that mean we can build a universal linux executable file?
All Linux distributions use the same binary format ELF, but there is still some differences:
different cpu arch use different instruction set.
the same cpu arch may use different ABI, ABI defines how to use the register file, how to call/return a routine. Different ABI can not work together.
Even on same arch, same ABI, this still does not mean we can copy one binary file in a distribution to another. Since most binary files are not statically linked, so they depends on the libraries under the distribution, which means different distribution may use different versions or different compilation configuration of libraries.
So if you want your program to run on all distribution, you may have to statically link a version that depends on the kernel's syscall only, even this you can only run a specified arch.
If you really want to run a program on any arch, then you have to compile binaries for all arches, and use a shell script to start up the right one.
All Linux ports (that is, the Linux kernel on different processors) use ELF as the file format for executables and libraries. A specific ELF binary is labeled with a single architecture/OS on which it can run (although some OSes have compatibility to run ELF binaries from other OSes).
Most ports have support for the older a.out format. (Some processors are new enough that there have never existed any a.out executables for them.)
Some ports support other executable file formats as well; for example, the PA-RISC port has support for HP-UX's old SOM executables, and the μcLinux (nonmmu) ports support their own FLAT format.
Linux also has binfmt_misc, which allows userspace to register handlers for arbitrary binary formats. Some distributions take advantage of this to be able to execute Windows, .NET, or Java applications -- it's really still launching an interpreter, but it's completely transparent to the user.
Linux on Alpha has support for loading Intel binaries, which are run via the em86 emulator.
It's possible to register binfmt_misc for executables of other architectures, to be run with qemu-user.
In theory, one could create a new format -- perhaps register a new "architecture" in ELF -- for fat binaries. Then the kernel binfmt loader would have to be taught about this new format, and you wouldn't want to miss the ld-linux.so dynamic linker and the whole build toolchain. There's been little interest in such a feature, and as far as I know, nobody is working on anything like it.
Almost all linux program files use the ELF standard.
Old Unixes also used COFF format. You may still find executables from times of yore in this format. Linux still has support for it (I don't know if it's compiled in current distros, though).
If you want to create a program that runs an all Linux distributions, you can consider using scripting languages (like Python and Perl) or a platform independent programming language like Java.
Programs written in scripting languages are complied at execution time, which means they are always compiled to match the platform they are executed on, and, hence, should always work (given that the libraries are set up properly).
Programs written in Java, on the other hand, are compiled before distributing them, but can be executed on any Linux distribution as long as it has a Java VM installed.
Furthermore, programs written in Java can be run on other operating systems like MS Windows and Mac OS.
The same is true for many programs written in Python and Perl; however, whether a Python or Perl program will work on another operating system depends on what libraries are used by that program and whether these libraries are available on the other operating systems.