Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Jan 1999 16:47:17 -0700
From:      Nate Williams <nate@mt.sri.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        nate@mt.sri.com (Nate Williams), java@FreeBSD.ORG
Subject:   Re: TowerJ for FreeBSD
Message-ID:  <199901262347.QAA15778@mt.sri.com>
In-Reply-To: <199901262327.QAA05210@usr01.primenet.com>
References:  <199901262226.PAA14679@mt.sri.com> <199901262327.QAA05210@usr01.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[ Your mailer is scrambling everyone's email address by assuming they're
all on primenet.com ]

> > > > Really hard.  Hard enough that it will probably never be done.  See
> > > > postings on hackers on this where Terry Lambert bogusly declared it was
> > > > trivial without understanding the details.
> > > 
> > > The library is ELF, and is unrelocated, so it isn't Solaris specific
> > > excepet for partially preresolved jump table vector names.
> > 
> > Wrong.  It makes Solaris system calls, using Solaris parameters and
> > Solaris defines.
> 
> The libc does.  The other libraries make their calls by way of libc
> symbols.  You replace the libc, you replace the calls (but not the
> parameters).
> 
> The parameters are only problematic if people are doing complicated
> things, like directly controlling devices, ejecting CDROM's, etc..

Or complicated things like select, poll, and ioctl, network calls,
writing, signals, etc...  You know, very OS specific calls that differ
greatly between OS's.

(And yes, I'm very aware of these because of the JDK porting effort.)

> > > For example, a number of people have been using the Solaris CDE ELF
> > > library to get an ELF Motif 2.0 implementation that they can link
> > > against, since Sun used to offer the thing for download from their
> > > WWW site, and you can get it on the Solaris "free" ($15) CDROM.
> > 
> > Nobody has been using the Solaris CDE ELF library to build FreeBSD
> > binaries.  As was pointed a while back, you can't 'mix' a Solaris
> > library and a FreeBSD binary.  I'd even buy you dinner if you can
> > make anything beyond a simple toy application work with the Solaris
> > library.  

No comment?

> > I've got a FreeBSD native application that uses Motif.  I'll bet you
> > dinner that you can't make it work with the Solaris ELF library.
> 
> Static library?  This is almost worth giving up my Motif-taint-free
> status to make work...

Shared library, since that's all we have available to us, and what you
claimed could be done above.  Although, I'd settle for a static link.
(Although I have access to an FreeBSD ELF/Motif library. :)

> > > It's pretty trivial (contrary to Nate's claims) to find the list of
> > > interfaces affected by just truing to link the Motif library
> > > directly.  You'll get a list of unresolved externals.
> > 
> > Prove it.  Really, I'd love for you to prove me wrong.
> > 
> > Hand-waving a long email messages stating that it's trivial mean nothing
> > when in fact it doesn't work.
> 
> Actually, if you look over the -current list archives, you'll see that
> someone tried and failed to link the Solaris Motif libraries.

Mike talked about it trying it, but I don't remember him giving any
details.

> They
> ended up with only a few unresolved symbols, most ending with "64".  O
> believe the total was less than 10.

See above.  Also, the linking is the *easy* part.  It's providing the
'shim' to convert all of the calls to/from the shlib that's the hard
part.

> That should mean that you could get it linking with about 30 minutes
> of light work, and that you could probably have trivial programs (e.g.,
> the ones in the "Young" and "O'REilly" Motif books) running in a relatively
> short period of time (say a day at most, with SEF's truss and Mark's
> Solaris ABI KLD in hand).

I disagree.  Select/poo is used all over the place in Motif (the event
libs), so I doubt even trivial applications would work.

> > Issues such as system calls (which are the biggest problem),
> 
> System calls aren't really relevent, since the calls are by way of
> whatever libc you link against.

Sure they are.  The Solaris ELF library assumes that the constants are
the same for all the function calls in FreeBSD as they were in Solaris,
which is the wrong assumption.  Also, you have to assume that none of
the shlib include files (the ELF Motif and/or JIT) also make any
assumptions about the OS in question that are invalid (filename size,
etc...)

> System calls would be an issue if I were trying to use Solaris's
> libc; I'm not.

You have to look like Solaris's libc, because the shlib is expecting
that 'ioctl(a, b, c)' looks the same in FreeBSD as it does in Solaris,
as the JIT is calling them.

> JDK libraries would probably take up to five days to make work, if you
> had the working Motif libraries on which JAVA depends on Solaris in hand.

Right.  As with all of your ideas, one/two weeks worth of work and
things'll be there, so why bother.  Thank goodness you aren't in
management, else you'd be killed by your own staff. :)

> > different library functions, etc.. can all be worked around, but
> > not 'trivialy'.
> 
> I think you are misunderstanding my use of the word "trivial".  It's
> a measure of complexity of the problem.  If you want, you can translate
> it each time you see it to "there's not a lot of thought required".

Then use a different word instead.  Trivial implies 'easy, nothing much
to do'.  Also, I disagree that it's trivial.  *MOST* of the work is
'easy stuff' (just like most of the stuff we do at our jobs), it's the
last 10% that's hard.  The hard part is rarely designing the algorithms,
it's trying to make it 'fit' into the already existing framework w/out
breaking everything else.

There is where most of the challenge in software is nowadays.  Anyone
can 'make it work', but few can make it work well and still keep it
extendable/understandable/maintainable.

Working for one of the world's largest research institute makes it
obvious (at least to me) that really good ideas come along infrequently.
Anyone can come up with a solution that works in a 'box', but making it
work outside the box is something quite different.  Generic solutions to
existing problems take 'engineering' solutions, and involve mostly
'trivial' (your word, not mine) work.

Your definition of the word trivial implies that it's 'beneath you',
which is just your ego getting out of control. ;)




Nate

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-java" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901262347.QAA15778>