[lsb-discuss] LSB 3.2 Compliance Report: Sun JRE 6 (update 5) on x86

Wichmann, Mats D mats.d.wichmann at intel.com
Thu Apr 10 18:59:51 PDT 2008

Okay, here's some new information from the openjdk/icedtea
implementation on Fedora Development (soon 9).  I presume this is
similar code to what we'd see in older java codes that may have been a
basis for Sun, IBM or other released versions.
syscall is used in two places, for a couple of reasons, in the
Linux-specific vm code.
reason #1 is to try to find the kernel thread ID of the current running
thread. This ID will be used for later digging in - you guessed it,
/proc. Apparently they've determined that getpid() provides the right
information under LinuxThreads, but under NPTL it returns the same for
all threads as specified by POSIX and they want the kernel thread ID.
this is "gettid" which has a manpage, but no glibc wrapper, so the only
way to ask for this specific function - assuming it's needed - is
one of the places where this is used is to help determine the number of
processors.  according to the comments, the call
sysconf(_SC_NPROCESSORS_ONLN), which is now allowed by LSB, is
unreliable, and in particular returns 1 inside a chroot no matter what
the real number is. So if the call returns 1, further digging is done,
in /proc, using the gettid result described above.
later in the same source file, /proc/self/maps is also used.
the same source file also looks for stack information by first dlsym'ing
__libc_stack_end, not an LSB symbol but we wouldn't detect this usage
since it's runtime (hmmm), then falling back to /proc/self/stat.
/proc/meminfo is also used, to do some grubbing around in the case of
large page sizes.
it also looks at, and sometimes tries to modify /proc/sys/kernel/shmmax
and /proc/sys/vm/nr_hugepages.
there's even more /proc grubbing:  /proc/self/task/<tid>/stat, 
Shades of our discussion today, I guess.
reason #2 for syscall is:
"fork() in LinuxThreads/NPTL is not async-safe. it needs to run
pthread_atfork handlers
and reset pthread library. All we need is a separate process to execve.
Make a direct
syscall to fork process.  On IA64 there's no fork syscall, we have to
use fork() and
hope for the best..."
"execve() in LinuxThreads will call pthread_kill_other_threads_np()
first to kill
every thread in the thread list.  Because this list is not reset by
fork() (see notes above)
execve() will instead kill every thread in the parent process.  We know
this is the
only thread in the new process, so make a system call directly.
IA64 should use normal execve() from glibc to match the glibc fork()
Hope this helps some wise person consider what we should do.
The syscall stuff is "bug workaround" essentially; the /proc mucking
looks considerably more difficult to rip out.


From: lsb-discuss-bounces at lists.linux-foundation.org
[mailto:lsb-discuss-bounces at lists.linux-foundation.org] On Behalf Of
Alexey Khoroshilov
Sent: Thursday, April 10, 2008 10:12 AM
To: lsb-discuss at lists.linux-foundation.org
Subject: Re: [lsb-discuss] LSB 3.2 Compliance Report: Sun JRE 6 (update
5) on x86

Alexey Khoroshilov wrote: 

	Please find attached a report on LSB 3.2 Compliance of Sun JRE 6
(update 5) package for x86. 
	Hopefully it can help us with discussions on getting LSB
compliant JRE and expansion of the standard. 

Let me summarize the report on getting LSB compliant Sun JRE.

The report identifies several action items to be done by the LSB
Workgroup. At the same time the goal is not feasible without help from
the side of the JRE development team.

The action items for the LSB Workgroup are as follows:
AI-1-1. Consider possibilities to add into LSB 4.0 the interfaces
required by Sun JRE. 
        If necessary initiate discussion with the JRE development team
on alternative solutions.
AI-1-2. Define LSB position regarding to pthread interfaces in libc.
AI-1-3. Investigate problems with ELF sections detected by lsb-appchk:
          - Section .eh_frame: sh_flags is wrong. expecting 2, got 3
          - Section .gcc_except_table: sh_flags is wrong. expecting 2,
got 3
          - Dynamic Tag 0x6ffffffb unknown
AI-1-4. Investigate problems with RPM packaging in light of RPM
specification uplift.

The action items for the JRE development team are as follows:
AI-2-1. Escape of superfluous library dependencies. If it is impossible
report the reasons.
AI-2-2. Consider possibilities to replace usage of syscall() interface.
        Provide us details if it is not possible.
AI-2-3. Investigate possibilities to eliminate dependincies on isnanf,
atexit, __ctype_b, __ctype_tolower and __ctype_toupper. The alternatives
are __isnanf, __cxa_atexit, __ctype_b_loc, __ctype_tolower_loc and
__ctype_toupper_loc correspodingly.
AI-2-4. Investigate possibilities to eliminate dependincies on __snd_*
interfaces by using snd_* analogues.
AI-2-5. Make sure that usage of ioctl() and dlopen() satisfies to LSB
AI-2-6. Change installation location from /usr/java/jre1.6.0_05 to
/opt/[sun|java]/jre1.6.0_05 according to FHS.
AI-2-7. (opt) Consider LSB recommendations on usage obsolete interfaces.

Comments are welcome.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080410/46bf96f6/attachment.htm 

More information about the lsb-discuss mailing list