Re: Trying to.... It's amazing and it works!

[Manu Valderrama]

Manuel Menal wrote:

> > Just the little help I was needing ; although I must admit that I have had
> > very much good luck. This was finally the keys to solve the problem :
>
> > (1) allocate the port :
>
> > mach_port_allocate( mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &receive_port 
> );
>
> -> (2) insert a send right in the port : <- OUT!!
(2) Insert to the port name "receive_port" a send right

> > mach_port_insert_right( mach_task_self(), receive_port, MACH_PORT_RIGHT_SEND,
> > MACH_PORT_NULL );
>  
Then after these two operations the port name "receive_port" contains 
two port rights, a receive
port ( as consecuence of this right a real port was allocated inside the 
kernel; my port name
"receive_port" is just the identification that the real port has in the 
task's port name space ),
and a send right.

This means that a port name can contain both receive and send right; 
when a send once right
is needed, every send one right must have its own port name ( send once 
right is different ).
Is this the idea ? I hope yes!

In this case it would be more easy to allocate the port in this way ( I 
have made it, and
it has worked ) :

mach_port_allocate( mach_task_self(), 
		MACH_PORT_RIGHT_RECEIVE|MACH_PORT_RIGHT_SEND, 
		&receive_port );


> Oh, it seems you are confused here. Let me quote from Mach 3 Kernel
> Principles, page 12:
>
>   A port can only be accessed via a port right. A port right is an
>   entity that indicates the right to access a specific port in a
>   specific way. 
>
> So, inserting a send right in the port doesn't make sense. You should've
> said something like: "create a send right to the port". Remember that
> the port is ``immaterial''. It is just ``materialized'' via port
> rights. The mach_port_t variable you have is _just_ a port right for a
> specific port. That's what you provide to mach_msg and other functions,
> and what mach_port_insert_right returns in its penultimate argument.
>    
> > (3) fill the correct msgh_bits :
>
> > my_message.head.msgh_bits = MACH_MSGH_BITS( MACH_MSG_TYPE_MAKE_SEND );
>  
Oh! Sorry, I did mean MACH_MSGH_BITS_REMOTE( ... ); although in this case
in still confused; other combination that has worked is :

my_message.head.msgh_bits = MACH_MSG_TYPE_MAKE_SEND;


with no macro!!!... I'm double confused by these reasons :

(1) in the case just above :

msgh_bits is of type mach_msg_bits_t, and MACH_MSG_TYPE_MAKE_SEND is
of type..... mach_msg_type_name_t

in the case with the macro :

(2) I use the macro to encode the MACH_MSG_TYPE_MAKE_SEND macro
( sounds strange so many macros!! ); but I thought that the above macro has
to be used when in your message you wanted to send a right!!....

Maybe the best way to go ahead at this moment is trying mig.
Could help to understand the mach ipc details.

Anycase, I'm in doubt with you for your help. Thanks!

Bye!

> Well, the MACH_MSGH_BITS macro takes 2 arguments. Remember page 335 of
> Mach 3 Kernel Interfaces. Either you should carry a send right (and make
> it via MACH_MSG_TYPE_MAKE_SEND) in the same message by which you carry
> your integer (you can have multiple mach_msg_type_name_t/data couple in
> your structure, so you can carry multiple things in a single message),
> either you create it via mach_port_insert_right. I think you should make
> as few Mach calls as possible, so it's maybe a good solution to just
> make _one_ message, and probably to do _both_ sending and receiving
> operation in the same mach_msg call, as described in the guides. This
> way you could have only 5 Mach calls (Cthreads call excluded) (or 4 if
> you decide to do it another, interesting, way, which is by using only
> one port and therefore using some cthreads structures to do some
> "scheduling", but you should only do it when you've already done the
> common way, with two ports). 
>
> > but the happyness is not complete; as you ( or anybody that knows enough about
> > mach ) would
> > appreciate, I filled all the "mach_msg_type_name_t" variables with random 
> values
> > until the code
> > worked ( -> MACH_MSG_TYPE_MAKE_SEND; I think it does not make very much sense
> > in the msgh_bits field !! ).
>
> Depends on what you carry. See what I've said before. 
>
>