<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>syscall is used in two places, for a couple of reasons, in
the Linux-specific vm code.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>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. </FONT></SPAN><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>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
syscall(SYS_gettid).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>later in the same source file, /proc/self/maps is also
used.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>/proc/meminfo is also used, to do some grubbing around in
the case of large page sizes.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>it also looks at, and sometimes tries to modify
/proc/sys/kernel/shmmax and /proc/sys/vm/nr_hugepages.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>there's even more /proc grubbing:
/proc/self/task/<tid>/stat, </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>Shades of our discussion today, I
guess.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>reason #2 for syscall is:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>"fork() in LinuxThreads/NPTL is not async-safe. it needs to
run pthread_atfork handlers</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>and reset pthread library. All we need is a separate
process to execve. Make a direct</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>syscall to fork process. On IA64 there's no fork
syscall, we have to use fork() and</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>hope for the best..."</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>"execve() in LinuxThreads will call
pthread_kill_other_threads_np() first to kill</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>every thread in the thread list. Because this list is
not reset by fork() (see notes above)</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>execve() will instead kill every thread in the parent
process. We know this is the</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>only thread in the new process, so make a system call
directly.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>IA64 should use normal execve() from glibc to match the
glibc fork() above."</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>Hope this helps some wise person consider what we should
do.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>The syscall stuff is "bug workaround" essentially; the
/proc mucking</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2>looks considerably more difficult to rip
out.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B>
lsb-discuss-bounces@lists.linux-foundation.org
[mailto:lsb-discuss-bounces@lists.linux-foundation.org] <B>On Behalf Of
</B>Alexey Khoroshilov<BR><B>Sent:</B> Thursday, April 10, 2008 10:12
AM<BR><B>To:</B> lsb-discuss@lists.linux-foundation.org<BR><B>Subject:</B> Re:
[lsb-discuss] LSB 3.2 Compliance Report: Sun JRE 6 (update 5) on
x86<BR></FONT><BR></DIV>
<DIV></DIV><TT>Alexey Khoroshilov wrote:</TT>
<BLOCKQUOTE cite=mid:47FC6429.3010501@ispras.ru type="cite"><TT>Please find
attached a report on LSB 3.2 Compliance of Sun JRE 6 (update 5) package for
x86. <BR><BR>Hopefully it can help us with discussions on getting LSB
compliant JRE and expansion of the standard. <BR></TT></BLOCKQUOTE><TT>Let me
summarize the report on getting LSB compliant Sun JRE.<BR><BR>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.<BR><BR>The action items for the LSB Workgroup are as
follows:<BR><B>AI-1-1.</B> Consider possibilities to add into LSB 4.0 the
interfaces required by Sun JRE. <BR>
If necessary initiate discussion with </TT><TT>the JRE development team</TT><TT>
on alternative solutions<B>.<BR>AI-1-2.</B> Define LSB position regarding to
pthread interfaces in libc.<BR><B>AI-1-3.</B> Investigate problems with ELF
sections detected by
lsb-appchk:<BR> - Section
.eh_frame: sh_flags is wrong. expecting 2, got
3<BR> - Section
.gcc_except_table: sh_flags is wrong. expecting 2, got
3<BR> - Dynamic Tag
0x6ffffffb unknown<BR><B>AI-1-4.</B> Investigate problems with RPM packaging in
light of RPM specification uplift.<BR><BR>The action items for the JRE
development team are as follows:<BR><B>AI-2-1.</B> Escape of superfluous library
dependencies. If it is impossible report the reasons.<BR><B>AI-2-2.</B> Consider
possibilities to replace usage of syscall()
interface.<BR> Provide us details if
it is not possible.<BR><B>AI-2-3.</B> 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.<BR><B>AI-2-4.</B> Investigate
possibilities to eliminate dependincies on __snd_* interfaces by using snd_*
analogues.<BR><B>AI-2-5.</B> Make sure that usage of ioctl() and dlopen()
satisfies to LSB requirements.<BR><B>AI-2-6.</B> Change installation location
from /usr/java/jre1.6.0_05 to /opt/[sun|java]/jre1.6.0_05 according to
FHS.<BR><B>AI-2-7.</B> (opt) Consider LSB recommendations on usage obsolete
interfaces.<BR><BR>Comments are welcome.<BR><BR>-- <BR>Regards, <BR>Alexey
<BR><BR></TT></BODY></HTML>