On Mon, Feb 19, 2001 at 03:14:43PM +0100, Johan Rydberg wrote:
> "Eray Ozkural (exa)" wrote:
> Don't you mean Berkeley? Well, here's an URL to the Sprite project at
> Berkeley:
>
> http://www.cs.berkeley.edu:80/projects/sprite/sprite.html
Arrgh. Sure, Berkeley... The project is over but some
"Eray Ozkural (exa)" wrote:
> > > You mean a burst transfer. That's done in parallel programming. Many high
> > > level libraries take advantage of that. It is ultimately the task of
> > > message passing subsystem though. Think an optimizing msg handler. Of
> > > course you need some abstraction
> > By the way Elliot Lee, the instigator of the ORBit
> > project, thinks that he can, without violating the
> > CORBA spec, get the cost of a CORBA call darn
> close to
> > that of a standard library call, where a local
> > implementation of the requested service is
> > available.
>
> Do you ha
On Wed, Feb 14, 2001 at 03:21:16AM +0100, Farid Hajji wrote:
> > We're talking about a microkernel arch, but still I'm
> > not sure if turning hurd into gnome is a good idea.
> [...]
> > Interoperability is a good idea, but if you bloat the
> > whole code with interoperability stuff then it blows
Development cost would be the most prominent here. This would
> take a lot of developer time and effort, which may be
> a hindrance in the future: when hurd needs more subsystems.
The problem with the Hurd right now is not how to extend it, but
how to _simplify_ it so that it can be more easily ext
On Sun, Feb 11, 2001 at 03:04:48PM +0200, Eray Ozkural (exa) wrote:
> Marcus Brinkmann wrote:
> >
> > I think it is single server, not multi server. There are many single server
> > systems, and they share the same deficiencies as monolithical kernels.
> > The linux kernel is also "modular", the
Mridul Jain wrote:
> > Anyway, those
> > people have been there'n' done that, and AFAIK they
> > aren't trying to
> > facilitate a multi-language development for their
> > modular
> > kernels, why not?
>
> Come on let's not bring in Billy here.Ok you can be
> happy coding in VB thro'out.
>
Bill
Marcus Brinkmann wrote:
>
> I think it is single server, not multi server. There are many single server
> systems, and they share the same deficiencies as monolithical kernels.
> The linux kernel is also "modular", the term is not clear and as thus it is
> confusing to use it.
Let me just confes
Ognyan Kulev wrote:
>
> On Sat, Feb 10, 2001 at 04:15:16PM +0200, Eray Ozkural wrote:
> > On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> > > One beautiful solution will be batching many IPC requests in one context
> > > switch, e.g. (open,read,close).
> >
> > You mean a burst tra
On Thu, Feb 08, 2001 at 04:31:54AM -0800, Mridul Jain wrote:
>
> hi,
> > > I can notice the messages as they are being sent
> > on this GNOME
> > > desktop. That would not make a good bet for a hurd
> > server.
> >
> > IMHO CORBA can be as fast as Mig, even faster.
> >
> yes I agree that IPC is
hi
> Merging the
> efforts with GNOME project will be A Good Thing
> (GConf, ...) - I see it as
> the most progressive GNU project (Unix sucks, but
> we'll fix it:-))).
Yes that is a powerful thing.Especially since ORBIT is
a good choice for such a stuff,I think GNOMERS will be
very interested.Le
On Fri, Feb 09, 2001 at 05:58:33PM +0200, Eray Ozkural (exa) wrote:
> Well he said performance is not really an issue,
Sorry, but I must insist to be pedantic here. I said that performance is not
a concern, not that it is not an issue. Performance is very important, but I
don't think one needs to
On Sat, Feb 10, 2001 at 04:15:16PM +0200, Eray Ozkural wrote:
> On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> > One beautiful solution will be batching many IPC requests in one context
> > switch, e.g. (open,read,close).
>
> You mean a burst transfer. That's done in parallel pr
On Sat, Feb 10, 2001 at 03:12:46PM +0200, Ognyan Kulev wrote:
> One beautiful solution will be batching many IPC requests in one context
> switch, e.g. (open,read,close).
You mean a burst transfer. That's done in parallel programming. Many high
level libraries take advantage of that. It is ultim
On Fri, Feb 09, 2001 at 04:11:19PM +0100, Marcus Brinkmann wrote:
> Of course, but any message passing only adds a constant overhead to a single
> message. Performance increase can also be achieved by adding new interfaces,
> which remove the need to send several messages (by replacing them with a
From: Marcus Brinkmann <[EMAIL PROTECTED]>
Subject: Re: MIG->Corba (performance)
Date: Fri, 9 Feb 2001 16:11:19 +0100
> Of course, but any message passing only adds a constant overhead to a single
> message. Performance increase can also be achieved by adding new interfaces,
>
--- "Eray Ozkural (exa)" <[EMAIL PROTECTED]>
wrote:
> Well he said performance is not really an issue, but
> this
> is one thing that linux people have been bashing
> hurd with.
> Performance has always been a primary design
> objective in OS
> design.
Well don't you assume that the performance
On Fri, Feb 09, 2001 at 05:58:33PM +0200, Eray Ozkural (exa) wrote:
> Well he said performance is not really an issue, but this
> is one thing that linux people have been bashing hurd with.
> Performance has always been a primary design objective in OS
> design.
I my experience Linux zealots who
Mridul Jain wrote:
>
> Hey things are cool!!It's just a useful discussion.:-)
>
All right :)
> > So, you're saying that a well optimized ORB can be
> > just as good as MIG.
> > That raises two other questions:
> > 1) Is CORBA going to be as slow as MIG?
> > 2) Is MIG slow enough?
>
> I th
On Fri, Feb 09, 2001 at 03:36:37PM -0500, Ingmar Schuster wrote:
> > Performance is not really the concern here, although it is good to know
> > that
> > a CORBA implementation can make special short cuts on the Hurd.
>
> Isn't it? IMHO such an important interface defenitely should be fast.
Of c
> Performance is not really the concern here, although it is good to know
> that
> a CORBA implementation can make special short cuts on the Hurd.
Isn't it? IMHO such an important interface defenitely should be fast.
Ingmar Schuster
___
Bug-hurd mai
hi,
> Please take my comments lightly, they are meant to
> be humorous to
> an extent. [no flames intended]
Hey things are cool!!It's just a useful discussion.:-)
> So, you're saying that a well optimized ORB can be
> just as good as MIG.
> That raises two other questions:
> 1) Is CORBA goin
> "Joshua" == Joshua Rosen <[EMAIL PROTECTED]> writes:
Joshua> PERL might be a good choice for the RCS-translator that
Joshua> I'd like to write
Not to mention other languages that we haven't even mentioned here.
eg. C++, Ada, etc (the list goes on).
I think for The Hurd to achi
On Thu, Feb 08, 2001 at 10:15:59PM +0200, Eray Ozkural (exa) wrote:
> So, you're saying that a well optimized ORB can be just as good as MIG.
> That raises two other questions:
> 1) Is CORBA going to be as slow as MIG?
> 2) Is MIG slow enough?
Performance is not really the concern here, altho
On Thu, Feb 08, 2001 at 01:05:30PM -0800, Jeff Bailey wrote:
> On Thu, Feb 08, 2001 at 10:15:59PM +0200, Eray Ozkural (exa) wrote:
>
> > For instance, do you really need to write hurd servers in different languages?
> > How useful/suitable would a server written in "perl" be? These are the kind
>
Eray Ozkural (exa) writes:
> For instance, do you really need to write hurd servers in different languages?
> How useful/suitable would a server written in "perl" be?
Whell, I, for one, would love to see RMS's original projection that "Both C
and Lisp will be available as system programming lan
On Thu, Feb 08, 2001 at 10:15:59PM +0200, Eray Ozkural (exa) wrote:
> For instance, do you really need to write hurd servers in different languages?
> How useful/suitable would a server written in "perl" be? These are the kind
> of questions one should consider before writing a big amount of code
hi,
Igor Khavkine wrote:
>
> CORBA is only a source level standard. It is not restricted to IIOP
> or any other message passing protocol, the so to say "backend"
> can be changed according to need. For example regular IPC on the same
> machine can be done through the Mach message passing facilit
hi,
> CORBA is only a source level standard. It is not
> restricted to IIOP
> or any other message passing protocol, the so to say
> "backend"
> can be changed according to need. For example
> regular IPC on the same
> machine can be done through the Mach message passing
> facilities, like
> MIG
On Thu, Feb 08, 2001 at 11:34:26AM +0200, Eray Ozkural (exa) wrote:
> Mridul Jain wrote:
> >
> > hi,
> > As I was preparing to work on the topic - Corba
> > replacement for MIG ;
>
> Make sure it doesn't turn out to yield a Java level performance. ;)
>
> That standard called Corba was not tailo
hi,
> > I can notice the messages as they are being sent
> on this GNOME
> > desktop. That would not make a good bet for a hurd
> server.
>
> IMHO CORBA can be as fast as Mig, even faster.
>
yes I agree that IPC is faster than vanilla IIOP.But
there are ways by which we can increase the
perform
On Thu, Feb 08, 2001 at 11:34:26AM +0200, Eray Ozkural (exa) wrote:
> That standard called Corba was not tailored for microkernel
> message passing.
>
> I can notice the messages as they are being sent on this GNOME
> desktop. That would not make a good bet for a hurd server.
IMHO CORBA can be a
Mridul Jain wrote:
>
> hi,
> As I was preparing to work on the topic - Corba
> replacement for MIG ;
Make sure it doesn't turn out to yield a Java level performance. ;)
That standard called Corba was not tailored for microkernel
message passing.
I can notice the messages as they are being sent
Hi,
> As far as I know MIG only supports C. Modifying MIG
> to support other
> languages would probably not be worth the effort.
> Even the C code
> that it generates isn't that great either.
Yes that effort is not worth it!!!
> The more obscure featres of MIG support the more
> obscure featu
On Thu, Feb 08, 2001 at 09:14:57AM +1100, Brian May wrote:
> > "Mridul" == Mridul Jain <[EMAIL PROTECTED]> writes:
[snip]
> Mridul> protocol is that It is the Corba standard.If I want a
> Mridul> "TRUE" Corba implementation in GNUMach/HURD then the
> Mridul> protocol should be II
hi,
As I was preparing to work on the topic - Corba
replacement for MIG ;
Markus and Roland adviced that I post the topic on
[EMAIL PROTECTED] so as
to get input from others.I waited for some time to do
some homework and
was discussing with Eric Edie from utah about some
issues and he was of great
On Wed, 10 May 2000, Martin v. Loewis wrote:
> No, you are right. DII and DSI and part of the standard. They are just
> not very useful, except for very specialized applications. Instead of
> the DII and the DSI, those applications could use an internal API of
> the ORB as well - for example, peo
Date: Tue, 9 May 2000 22:55:21 +0500 (GMT-5)
From: Sergey Izvoztchikov <[EMAIL PROTECTED]>
On Wed, 10 May 2000, Mark Kettenis wrote:
> Indeed. I don't really have experience with CORBA, but I don't think
> the issues in this thread are relevant in this stage of Hurd
> developm
> As I understand ORBit is going to have DII, DSI in near feature.
> And I think that DII and DSI supposed to be in ORB. Correct me
> if I'm wrong.
No, you are right. DII and DSI and part of the standard. They are just
not very useful, except for very specialized applications. Instead of
the DII
On Tue, 9 May 2000, Martin v. Loewis wrote:
> > That's right. But It seems as a completely new environment for me and
> > it has less conformance even that ORBit.
> I won't argue about the "new environment" part. On the "less
> conformance" part, can you give me a feature that is implemented
>
On Wed, 10 May 2000, Mark Kettenis wrote:
> Indeed. I don't really have experience with CORBA, but I don't think
> the issues in this thread are relevant in this stage of Hurd
> development. Right now the core Hurd protocols are defined by the MiG
> .defs files. At one side this defines the C
If you don't like the corba->c idl mapping, bad luck, the servers are
implemented in C. However shifting to CORBA is nice as it opens the
possibility of C++ hurd servers. However there may be other reasons that C++
can't be used (I am not familiar w/implementation details of hurd servers).
If a c+
Date: Tue, 09 May 2000 13:09:59 -0400
From: Serguei Izvoztchikov <[EMAIL PROTECTED]>
Jeff Bailey wrote:
> I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have
> declined to add wrappers within their header files to permit linking from
> C++ programs, so I do
Date: Tue, 9 May 2000 23:28:58 +0200
From: "Martin v. Loewis" <[EMAIL PROTECTED]>
[ This is not really directed to you Martin, but the last line of this
message just provided a convenient point to jump in the discussion. ]
> > No, it isn't. Its license is more liberal than the GPL.
> I just want to start with most conformant ORB. I suppose CORBA
> developers may need these parts.
A check-box point of view may not give you a correct answer to the
question "what ORB is most conformant". You'd also had to consider
correctness of the implementation. Also, there are other typica
"Martin v. Loewis" wrote:
> That is all still correct. However, instead of the BOA, ORBit supports
> the POA. Why do you need the DII, DSI, or IFR?
I just want to start with most conformant ORB. I suppose CORBA
developers may need these
parts.
> > To be clear. Is ILU GPL'ed ? I don't think so.
>
> I know that ORBit is used in GNOME, but according this page
> - http://www.vex.net/~ben/corba/orbmatrix.html
> ORBit lacks DII, DSI, IFR, BOA. Probably information on page is out of
> date.
That is all still correct. However, instead of the BOA, ORBit supports
the POA. Why do you need the DII,
"Martin v. Loewis" wrote:
> Hmm. If you want to use C, you'll have to use the C mapping, whether
> you like it or not (you could define an alternative C mapping, but it
> would not be much simpler). If you don't want to use the C mapping,
Agreed.
> what is then the problem with using C++?
I know
"Martin v. Loewis" wrote:
> I think both parts of that statement are incorrect. ORBit is not in
> early development; instead, it is a mature implementation which has
> been extensively tested as part of the Gnome project.
I know that ORBit is used in GNOME, but according this page
- http://www.ve
> I know this. It just has lack of basic CORBA services yet. I'm sure
> it will go well and have them latter, but now MICO/OmniORB2 support
> CORBA standard better.
Out of curiosity: Which of the "basic CORBA services" do you need that
are still missing, and what do you need them for?
> And seco
> Only one GPL ORB with C mapping is ORBit, which is still on early
> development stage.
I think both parts of that statement are incorrect. ORBit is not in
early development; instead, it is a mature implementation which has
been extensively tested as part of the Gnome project.
Furthermore, ther
Jeff Bailey wrote:
> I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have
> declined to add wrappers within their header files to permit linking from
> C++ programs, so I don't think they're going to change.
What is the reason ?
--
Best regards.
Sergey Izvoztchikov.
mailto
On Tue, May 09, 2000 at 11:54:57AM -0400, Serguei Izvoztchikov wrote:
> I know that most of Mach/Hurd servers were written in C,
> may be it's time to change this ?
I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have
declined to add wrappers within their header files to per
Jeff Bailey wrote:
> On Tue, May 09, 2000 at 09:59:02AM -0400, Serguei Izvoztchikov wrote:
> > Only one
> > GPL ORB with C mapping is ORBit, which is still on early development
> > stage.
>
> ORBit is the main ORB for GNOME, IIRC. You may want to use that, since
> it will probably be loaded on
On Tue, May 09, 2000 at 09:59:02AM -0400, Serguei Izvoztchikov wrote:
> Only one
> GPL ORB with C mapping is ORBit, which is still on early development
> stage.
ORBit is the main ORB for GNOME, IIRC. You may want to use that, since
it will probably be loaded on most Hurd systems once X is runn
Hi everybody !
My Name is Sergey Izvoztchikov AKA LezDep. I saw Subj inside Hurd Tasks
List.
Recently I want through some Mach3 documentation, found info about Flick
(http://www.cs.utah.edu/flux/flick) - Flexible IDL Compiler Kit, which
seems to allow
CORBA IDL to Mach3 IPC translation and checke
56 matches
Mail list logo
