<!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).&nbsp; 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>&nbsp;</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>&nbsp;</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.&nbsp; 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>&nbsp;</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.&nbsp; 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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial 
color=#0000ff size=2>there's even more /proc grubbing:&nbsp; 
/proc/self/task/&lt;tid&gt;/stat, </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</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>&nbsp;</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.&nbsp; 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>&nbsp;</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.&nbsp; 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.&nbsp; 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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</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>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=076253201-11042008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Section 
.eh_frame: sh_flags is wrong. expecting 2, got 
3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Section 
.gcc_except_table: sh_flags is wrong. expecting 2, got 
3<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - 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>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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>