OS-Design:Corba, Bonobo and XPCOM (Components)

[JoeKayzA]

Instead, i'd advocate for a repository (or an component-support server) to offer that information.

..or a set of support libraries at the server and client side, which could then be language dependent - for stub creation and stuff. A component support server will be needed too, anyway, IMO - just think of naming facilities.

cheers Joe

[Crazed123]

Lovely to see everyone is well and attached to their message-passing RPCs.

How would a kernel that actually has to "link" interfaces (ie: provide a method of in-memory access) without message passing represent interfaces? I can think of two ways: 1. Some sort of structure is kept by this kernel describing the interface well enough to build a table of method pointers for it, or 2. The kernel holds the IUnknown type interface and can call a method to obtain the method pointers on someone else's behalf.

[zloba]

I'm all in favor of components.

I've been using a COM-like infrastructure in all my userland development for a few years. It will certainly be in the OS when that comes.

Generally, I like the concept of requesting an object from an OS, a service or another app, and using it through interfaces.

It is also an abstraction layer, it allows you to ignore details that are not important at a particular level. Being able to ignore stuff is a Good Thing, your time and attention are precious and limited, much more so than CPU.
---

3. Must improve the development of applications making use of it.

Improvement is in the eye of the beholder. You may appreciate the technique and it may work well for your own development, but there will be those who disagree, maybe even the majority.
You get to decide who knows better.

I want to know if its worth the effort or just stick to normal libraries and dll's.

there are always tradeoffs. for me the advantage is clear.

I think they will be faster.

how much faster? is it worth it, in the long run? does it matter?
when you start by trying to optimize things, you end up losing sight of the big picture. it's called "premature optimization".

in most cases, the difference in speed won't matter. yes, there will be certain cases where it will make a huge difference - large, fast streams of data, video for example - but they can be handled specifically, one way or another.
---

I mean maybe developers are happy with straight libaries like on Linux. I don't know.

IMO, straight libraries are not acceptable. That's what all those ugly "configure" scripts are trying to handle, to determine what is present and what isn't, and a bunch of hairy #ifdef's all over the code. Every compilation, same thing. And when things change, you have to recompile. Software gets bound to specific .so filenames and versions. Configuring and compiling is the only reliable way to adopt software to your system, when it has such dependencies.

all things considered, it ends up being much slower and more bloated, and wastes everyone's time.

[Crazed123]

If components are used then configure scripts will be used to check for which components are around.

[zloba]

If components are used then configure scripts will be used to check for which components are around.

that won't be needed.
if the application may use an optional component/interface, it can supply its own IDL definition of it, and it can compile its (client) side of the functionality regardless whether or not the actual component is present, and still be ready to use the component whenever it gets installed.
--
p.s. That is assuming that somebody other than the developer will even want to compile it. The normal scenario would be where the developer compiles it "once and for all" and users install the binary and happily run it.

[JoeKayzA]

Lovely to see everyone is well and attached to their message-passing RPCs.

How would a kernel that actually has to "link" interfaces (ie: provide a method of in-memory access) without message passing represent interfaces? I can think of two ways: 1. Some sort of structure is kept by this kernel describing the interface well enough to build a table of method pointers for it, or 2. The kernel holds the IUnknown type interface and can call a method to obtain the method pointers on someone else's behalf.

I've still not quite understood how you want to 'link' against a symbol (an entrypoint, for e.g.) which resides in a remote address space, or even on a remote machine, without doing an rpc. Whether you send a message or do a thread-migration is a matter of taste/detail for now, but IMO you can't just link against such a remote procedure without using stub code or the like. (I know - you could link against an invalid address, intercept a page fault and hide the rpc - but is that really desirable?)

The marshalling of arguments and sending the message can be hidden by the helper libraries, as well as the negotiation about interface types and reflection, but why should the _kernel_ bother? At least in a microkernel, that is. If you use a modular/hybrid kernel, and use the component model at kernel space too, the issue will probably look quite different, however.

And please forgive me if I seem to not know how things _are_! ;D (Someone told me)

cheers Joe

[zloba]

Crazed123

what information about an interface (other than the obvious stuff like its identifiers) should be stored in that table?

I agree with JoeKayzA.

I had the idea of a channel (like a connection, a link between a client using a component and a server implementing a component).
Messages travel through channels - requests go in from the client and responses come out from the server.

The kernel's message passing infrastructure would then be responsible for routing messages between processes through channels. It would need to keep track of what channels a process has open, in what role, and what to do when a message arrives (unblock a waiting thread, signal a synchronization object, etc.)

Stubs/Proxies would use Channel Identifiers with message-passing system calls to send/receive a message. The message-passing API would be the only syscall API needed, and it would be encapsulated in an in-process runtime library and stubs/proxies.

A process may start with an initial (predefined?) Channel ID for a known or IUnknown interface, which can then be used to further navigate the options - connect to other objects, services, manage threads, etc.

As for stub/proxy generation - there would need to be mappings from IDL type system(s) to a particular language, type system and syscall API.
For example, strings may be mapped to malloc()'d or new()'d char buffers, some kind of String or IString objects or whatever - depends on how your program wants these things.

[JoeKayzA]

A process may start with an initial (predefined?) Channel ID for a known or IUnknown interface, which can then be used to further navigate the options - connect to other objects, services, manage threads, etc.

Looks quite similar to my concept , the main differences here are probably names. (I refer mostly to interface capabilities, which are quite the same as your channels) As for the initial capabilities, I wanted to implement the concept of constructors here. A constructor resideds either in the kernel, or another process, and is used to generate a new process - create the address space, create the initial thread(s), map code files into the address space, and hand the initial capabilities to the process. Which capabilities these are depends on the role of the process, and on the privileges. I think this concept is quite flexible, yet straight forward. New capabilities are obtained through naming directories, which can be arranged in a hierarchical manner - much like J2EE's JNDI, but system-wide. So you can easily restrict a process' activity by placing only a specific set of objects in the namespace(s) which it has access to.

As for stub/proxy generation - there would need to be mappings from IDL type system(s) to a particular language, type system and syscall API.
For example, strings may be mapped to malloc()'d or new()'d char buffers, some kind of String or IString objects or whatever - depends on how your program wants these things.

I don't know if the component system should really go _that_ deep. I mean, referencing a string by an interface sounds to me like overkill, at least. Or did I misunderstand the example?

cheers Joe

[Crazed123]

I don't know, I could easily see Pascal AnsiStrings implemented as an interface in C, seeing as C++ usually makes them classes.

They're implemented natively as a dynamically allocated block of memory starting with a length counter, followed by the actual character string and allocated with the RTL's interal allocator. Hence, C++ always treats such things as a class, with code inside to do allocation, reallocation, length setting, concatenation, and all of it. It makes a ton of sense to make such a class available as a component, thus never having to deal with F&(#ing char arrays again.

[zloba]

JoeKayzA

As for the initial capabilities, I wanted to implement the concept of constructors here. A constructor resideds either in the kernel, or another process, and is used to generate a new process - create the address space, create the initial thread(s), map code files into the address space, and hand the initial capabilities to the process. Which capabilities these are depends on the role of the process, and on the privileges. I think this concept is quite flexible, yet straight forward.

This way different binary formats can be handled and even different OS subsystems (implementing Win32, Linux, etc. - not necessarily interface-oriented - custom syscall handling can be plugged in - think Wine, how about running Win32 apps on your brand new OS from the start?).

So you can easily restrict a process' activity by placing only a specific set of objects in the namespace(s) which it has access to.

Exactly.
A process having an "environment" (initial or available capabilities) - what it is given to work with. For example, a GUI, an isolated Filesystem or Storage to keep settings, maybe a selected file to work with... If that can be restricted (no way to get outside of the box), security can be pretty much assured.
(not my original idea - this concept has been discussed before and generally agreed upon)

Does a screensaver need access to the root filesystem and network? All it needs is a preexisting screen canvas to draw upon..

btw,

I've not yet made up my mind about how to do those interface identifiers, however. (Somehow I'm not comfortable with the GUID-thing either)

What's uncomfortable about GUIDs?
There have been long flames where it has been concluded that:

GUIDs:
-are not 100% guaranteed to be unique ( but unique enough, IMO)
-are not human-readable and ugly to work with
-don't contain any hint as to the nature of the thing being named
Namespaces:
-are more flexible (for example, they can wrap GUIDs)
-provide a hint about the nature of the object they refer to

But, on the other hand,
GUIDs:
-are simple - "generate and forget",
-fixed-size - no need to handle potentially unbounded strings
-database is flat, unlike hierarchical namespaces.
Namespaces and names:
-have to be invented, managed, eventually will become crowded and will need to be redesigned
-have greater risk of collisions for independently created objects.

(anything I missed?)

anyway,

new capabilities are obtained through naming directories, which can be arranged in a hierarchical manner - much like J2EE's JNDI, but system-wide.

or it may be possible to use either or both (names and GUIDs) at the same time..
--

(about IString) I don't know if the component system should really go _that_ deep. I mean, referencing a string by an interface sounds to me like overkill, at least. Or did I misunderstand the example?

You understood correctly I just mentioned that as an arbitrary example. It may be an overkill, I dunno.
I've been using COM strings (the horror) from the beginning, though, and it hasn't caused much trouble so far, only the benefits:
- you can't overflow a well-tested IString, try as you might;
- different implementations can be used for different usage patterns..
Also, in Java, strings are proper objects, just like everything else..
But I don't want to make much of a point here. Just an example.
--
p.s. post collision
Crazed123:
(about strings) yes, indeed.

[zloba]

p.s. (about stings)
also, the reference couting is nice. no need to worry about the lifetime and when to delete.

[Crazed123]

Doesn't reference counting in C++ just mean that the object gets deleted when its last user releases it, and that if that never happens it never gets released?

And by going and looking in the ELF specs for myself I've actually managed to come up with an appropriate symbol-structure:

Code: Select all

TSymbolType = (stDataObject,stRoutine);

 TLinkSymbol = packed record
  {The name of the symbol.}
  strSymbolName: string;
  {The "value" of the symbol.  This could be an address or a real value.}
  lwValue: longword;
  {Data objects have a size, and this is it.  Otherwise 0.}
  wSize: word;
  {The type of symbol.}
  stType: TSymbolType;
 end;

That's just the information contained in any ELF file with some bits stripped away. Specifically, linking information only related to the file is stripped, and the symbol is assumed to be a global symbol. For what all that means beyond the comments, please consult the ELF specs.

[Legend]

p.s. (about stings)
also, the reference couting is nice. no need to worry about the lifetime and when to delete.

But you need to avoid cycles.