Date: Wed, 27 Jan 1999 22:50:45 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, nate@mt.sri.com, java@FreeBSD.ORG Subject: Re: TowerJ for FreeBSD Message-ID: <199901272250.PAA28087@usr05.primenet.com> In-Reply-To: <199901271953.MAA22848@mt.sri.com> from "Nate Williams" at Jan 27, 99 12:53:22 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > No comment?
> >
> > I know at least one person who is using the copy from the Sun
> > download. If you think I'm going to turn them in to be pursued
> > for license violation, you're crazy.
>
> I don't believe they are doing that, and your blowing smoke.
And you're a Sun/SPA shill. Are we done with name-calling?
> > And I think this "shim" is already well documented in the KLD for
> > the Solaris ABI module. Yes, I don't know for sure if the Solaris
> > JDK code will run under the ABI, but Oracle does, and so, apparently,
> > does Lotus Notes.
>
> We're talking two different problems here. One is a 'completely'
> separate SVR4 emulation model, and the other is hybrid of FreeBSD
> binaries and SVR4 (or other) shared libraries.
If Sun can do it in user space for SunOS 4.1.3 binaries, then Nate can
do it in user space for Solaris x86 binaries on FreeBSD.
This is not rocket science. This is not new territory. This is
not particularly challenging.
There's absolutely *no* difference between the argument conversion
code living in user space vs. it living in the kernel.
The Motif code does not have a large investment in the architecture
of the OS on which it is run -- it is portable code.
As I've previously stated, JAVA has a larger investment, but the
overall investment is small compared to, for example, a device
driver.
> > I know we all have a bias that the stuff we are doing is harder than
> > the stuff anyone else is doing, but frankly I can't see that the JDK
> > would be any more dependent than the other foreign binaries.
>
> Never said it was hard, but that it's alot of stuff to deal with since
> it requires alot of OS hooks, unlike most 'foreign binaries'. (Although
> I would guess that Oracle would be in the same class because it tries to
> do lots of 'performance' gaining calls.
Precisely why I cited the Oracle success, which you can independently
verify without having to "stoop" to granting me any credibility
whatsoever, since you are loathe to do so.
> > > I disagree. Select/poo is used all over the place in Motif (the event
> > > libs), so I doubt even trivial applications would work.
> >
> > Implementing select or poll is trivial. Yeah, some FreeBSD device
> > drivers may have to change; so what? Are we now talking about the
> > politics of the changes being committed? I don't care about politics,
> > if that's what we're doing.
>
> No, I meant that you have to determine *which* portion of the binary is
> calling select/poll (the FreeBSD portion or the Solaris portion), and
> then 'munge' the system to expect that.
The part that's linked with the Solaris SHIM library. E.g.:
,-------------------------------------------------------.
| FreeBSD Application |
`-------------------------------------------------------'
,---------------.,--------------------------------------.
| Solaris Motif || |
`---------------'| |
,---------------.| |
| libc SHIM || FreeBSD libc |
`---------------'| |
,----------------' |
| |
`-------------------------------------------------------' U
----------------------------------------------------------------
,-------------------------------------------------------. K
| FreeBSD ABI |
`-------------------------------------------------------'
In other words, the Solais Motif is modified to reference the SHIM
library as if it were the real libc, and the application, if it calls
"poll" (which it shouldn't, directly, since it should register an
AppInput source, if it were a correctly written Motif program), gets
the one from the real libc, *NOT* the shim.
This is all very easy to do using the tools John Birrell has provided,
and I really have a very hard time fathoming how this is any more
difficult to do than:
,-------------------------------------------------------.
| Solaris Application |
`-------------------------------------------------------'
,---------------.,--------------------------------------.
| Solaris Motif || |
`---------------'| Solaris libc |
,----------------' |
| |
`-------------------------------------------------------' U
----------------------------------------------------------------
,-------------------------------------------------------. K
| Solaris ABI |
| ,- ---------------------'
`-------------------------------',----------------------.
,--------------------------------' |
| FreeBSD ABI |
`-------------------------------------------------------'
It's the same damn wrapper code in both cases.
Except, well, you have to buy Solaris for the second one because you
need a legal copy of the Solaris libc because some frigging idiot
failed to statically link the Solaris Application, whereas I am free
to statically link the Solaris Motif library in the FreeBSD Application
and thereby avoid shooting myself in the head with the need to buy
Solaris anyway (which would beg the question of "Why the hell use
FreeBSD?".
> Basically, what you're trying to do is put a small-block Chevy engine in
> a BMW. Yes, it can be done, but it's not easy and the resulting car is
> probably worse than the original Chevy and the BMW in terms of
> performance and reliability.
No, that's not what I'm trying to do.
Eventually, FreeBSD should be made to conform to the Solaris ABI so
that applications don't need futzing -- EITHER by way of the ABI
module and a set of user space shared compatability libraries, or
by *only* a set of user space shared compatability libraries, or
both so that static and dynamic code will work, OR by way of the
Solaris ABI evolving into FreeBSD's native ABI.
> > For places this is not true, the answer is easy: change FreeBSD.
>
> Then you lose backwards compatability with FreeBSD, which arguably has a
> larger installed based than Solaris/x86. In other words, that's a
> stupid idea.
You mean like going to ELF.
No, you mean like unmapping page zero so that NULL dereferences cause
a fault.
No, wait, you mean like changing off_t to be a 64 bit value.
No, no, I have it, you mean like changing the arguments to the mount
system call.
AHA! You mean like the issetuid call addition.
No, you mean like changing the size/layout of the proc struct.
Come off of it. The Solaris ABI is a hell of a lot more stable, and
FreeBSD has a history of blanket violations that fall into the category
of what you have just called "a stupid idea".
Perhaps they all *were* "a stupid idea"; so what? Bite the bullet
one last time, and you get to avoid all of the future "a stupid idea"
that you're otherwise going to have to put up with.
> > Put it another way: there's no way we're going to be able to change
> > Solaris, so FreeBSD is the only thing that *can* be changed.
>
> Put it another way, cutting off your nose to spite your face is still
> stupid.
I understand the analogy.
Now explain how it applies: how is conforming to an ABI that buys
you 1000 times the number of commercial applications that Linux has
curtting off your nose?
> > > 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...)
> >
> > Yeah. I'm making the assumption that this is either true, or very
> > nearly true, and for the places it isn't that truss and a copy of
> > Solaris in hand (with it's truss to compare against) would be enough.
>
> All of a sudden this 'trivial' excercise is no longer trivial. (My
> definition, not yours.) You claimed a weeks work, and we're *way*
> beyond that now.
No, we're not. We are not over 40 hours work.
Pay me my going rate times 40 hours, and I'll do the work on a fixed
price contract. If I go over the time budget, it's costing me money
and you'll get to shoot me in the shorts with that fact.
> > The ioctl() is much less of a problem, IMO. I don't think it's that
> > frequent, and where it *is* used, I have no problem hacking up either
> > a non-weak wrapper in a stub or, preferrably, FreeBSD.
>
> IOCTL is used *ALL OVER* to setup socket timeout and such. It's
> non-trivial.
Bull.
> > No, the "why bother" comes from this not being intellectually
> > challenging, and me wanting to spend my free time being challenged;
> > otherwise I'd be watching TV.
>
> Terry, you have *yet* to complete a project in FreeBSD/NetBSD/etc.. ,
Actually, I have a number of projects that have been completed and
integrated into both systems.
LKM's were mine. People may say "they're stupid", but I've saved
the email where Garrett refused to allow a linker ton the kernel to
make them non-stupid.
FreeBSD only picked them up to keep up with NetBSD, in fact; they
had to be dragged kicking and screaming.
The FreeBSD kern/init_main.c and linker set based SYSINIT code is
mine. Booted your FreeBSD box lately?
> because as soon as they get 'interesting' (otherwise known as finishing
> the details that make the proof of concept usable beyond trivial
> applications), you throw your hands up in the air and claim the
> remaining stuff is 'trivial' to implement, when in fact as has shown
> that finishing those projects that have been adopted is *FAR* from
> trivial.
No, actually, it's because people who can't understand code won't
commit it without understanding the code fully, and they're not
willing to make the time commitment it takes to sit down and
understand it.
That's a significant difference between Linux and FreeBSD, in fact:
Linux doesn't give a flying about how the code works, it's enough
for them that it *works*, and understanding can come later. Yeah,
they've shot themselves in the foot a couple of times over that one,
but I've had a hell of a lot less trouble giving fixes back to FreeBSD
than I have to Linux.
> In other words, you're being lazy, and 'trivial' is a good excuse to
> avoid doing the hard work.
Pay me to do the boring work, and I will do the boring work. Otherwise,
get out of my face. You can't "piss me off" into compliance with your
whims about what you think I should or shouldn't be doing to help you.
> > Not to a mathematician or a scientist, it doesn't.
>
> Sure it does. You're no more a mathematician or a scientist more than
> I, and I consider the word incorrect.
Well, you're no more a lexicographer than Noah Webster, and he
disagrees with you:
] Main Entry: triv·i·al
] Pronunciation: 'tri-vE-&l
] Function: adjective
] Etymology: Latin trivialis found everywhere, commonplace, from trivium crossroads, from tri- + via way -- more at WAY
] Date: 1589
] 1 : COMMONPLACE, ORDINARY
] 2 a : of little worth or importance b : relating to or being the mathematically simplest case; specifically : characterized by having all
] variables equal to zero <a trivial solution to a linear equation>
] 3 : SPECIFIC 4
] - triv·i·al·ist /-&-list/ noun
] - triv·i·al·ly /-&-lE/ adverb
Should I believe you, or the dictionary?
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
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?199901272250.PAA28087>