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

Joseph Kowalski jek3 at sun.com
Thu May 8 13:15:41 PDT 2008


Jeff Licquia wrote:
> Joseph Kowalski wrote:
>> However, if these were the only two issues stopping lsb conformance, we
>> could probably get these addressed.  However, amongst a list of 80'ish
>> failures, we won't get much traction.  Let's just put these on the 
>> shelf as
>> "we think we have an answer".  When everything is on that shelf, then
>> we should look at the contents and decide if it is worth it.
>
> The idea is that most of the problems with Java can be fixed from the 
> LSB side fairly easily.  The syscall problems are the exception.  So 
> we're basically solving the hard problem first.
>
> Most of the rest of the problems shouldn't be too difficult to solve, 
> with some reservations (/proc and /sys being the other major one).
Hummm,.... The original posting on this thread (Alexey) had more than a
a few Sun AI's.  I guess we (Sun) just need to get "an answer" for those 
AI's
(or move them to the LSB workgroup).  (OK, 20'ish)
>>     2)   I don't see any definition of /proc in the LSB.  This means 
>> that although
>>           we have avoided not tripping over the entry points, we are 
>> still not
>>           conformant to a rather interesting interface.  Has this 
>> issue been
>>           discussed?
>
> Endlessly. :-)  (Didn't you have that contact at Sun on /proc?)
Yes, but only on the thread issues.  I'm not sure what I would ask him
about /proc at the moment.

BTW: He's the guy who originally created /proc at AT&T.
>
> Our current idea for fixing this is to possibly support a shim 
> library, which can export a stable ABI atop them, and adjust as needed 
> when /proc and /sys change.  This also allows us to control what 
> (possibly dangerous) information is exposed.
>
> But, to be clear, this can be trial use at best for 4.0, because no 
> such shim exists.  (Well, some do, but none is a "clear winner" at 
> this point.)
A "shim" library?  Why not just a library (interfaces) to get the 
information
directly from the kernel?  After all, the intent of /proc is to provide 
a window
into the kernel.  (Let me guess, the kernel guys and/or glibc 
maintainers aren't
interested.)

Also, a shim library is only as stable as the interfaces below it.  
Sure, it can
deal with syntax changes in the underlying provider, but not the semantics.
What happens if the value isn't provided at all (by /proc)?

The bottom line is "is the information stable"?  By design, /proc isn't very
stable, because a design point is to not constrain kernel innovation.  Any
application which depends upon the semantics, is going to fail regardless
of the way it gets the unstable information.  If the kernel innovates, the
application will fail.

I think the goal of the LSB (testing) should not give false positives when
an application an application grovels around /proc.

- jek3




- jek3





More information about the lsb-discuss mailing list