[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pthread assumption + starting real port
From: |
Farid Hajji |
Subject: |
Re: Pthread assumption + starting real port |
Date: |
Thu, 16 Nov 2000 03:26:43 +0100 |
> An alternative might be to extend pthreads with something similiar to
> Solaris' notion of "bound" threads. (Some details are in the paper
> that was cited here earlier).
Sounds like a reasonable assumption.
> > mom_message_short_t
> > mom_message_long_t
> >
> > The first one corresponding to L4's short messages that can be passed
> > in max. 3 registers (more on non x86 platforms) or that can be copied
> > in buffers on non L4 systems.
>
> As the amount of data that fits in a short message varies across
> platforms, one might consider parameterizing the types and perhaps
> also the ipc functions. Like
>
> ipc_send_1() for sending a single word,
> ipc_send_7() for sending seven words,
> ipc_send_4_vm() for sending 4 words and some memory pages.
>
> At each use of ipc (in the code), it should be obvious which call to
> use. On L4/x86, ipc_send_4() would be a macro expanding to something
> that sends an L4 long message, while on L4/sparc it it would send an
> L4 short message.
>
> Does that make sense?
Yes! That is an excellent idea! IMO this is the way to go and it is much
better and much more portable in any case.
> > Another way would be to relieve auth (or if you prefer l4-mach) from
> > capabilities queries by using another self-authenticating protocol
> > between the Hurd components (examples are kerberos-tickets,
> > public-keys (stored in a keys server), with or without encryption),
> > especially considering the potential port of the Hurd to a
> > distributed system.
>
> That's overkill for typical ipc, and would be real slow. I believe the
> right way to use cryptographic means for authentication is to use it
> to set up some kind of session, and then use some primitive and faster
> way for ipc within a machine.
>
> If my process exchanges messages with a process on some other machine,
> It will be talking to a local proxy, using fast local security
> mechanisms. The proxy, in turn, will encode the messages in some way
> and transfer them securely to the remote machine, using whatever
> cryptographic methods that make sense.
Here again, my point was not to use encrypted ipc (at least not on
the same host and the proxy is a good place to encrypt inter-node
messages) in general. I was more refering to signed tickets
("port rights") that would be trusted by all parties.
> /Niels
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
- Re: Pthread assumption + starting real port, (continued)
- Re: Pthread assumption + starting real port, Farid Hajji, 2000/11/14
- Re: Pthread assumption + starting real port, Farid Hajji, 2000/11/14
- Re: Pthread assumption + starting real port, Farid Hajji, 2000/11/14
- Re: Pthread assumption + starting real port, Farid Hajji, 2000/11/14
- Re: Pthread assumption + starting real port,
Farid Hajji <=
- Re: Pthread assumption + starting real port, Johan Rydberg, 2000/11/15
- Re: Pthread assumption + starting real port, Niels Möller, 2000/11/16
- Re: Pthread assumption + starting real port, Johan Rydberg, 2000/11/16
- Re: Pthread assumption + starting real port, OKUJI Yoshinori, 2000/11/16
- Re: Pthread assumption + starting real port, Niels Möller, 2000/11/16
- Re: Pthread assumption + starting real port, OKUJI Yoshinori, 2000/11/16
- Re: Pthread assumption + starting real port, Johan Rydberg, 2000/11/17
- Re: Pthread assumption + starting real port, OKUJI Yoshinori, 2000/11/17
Re: Pthread assumption + starting real port, Farid Hajji, 2000/11/16