[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shared-Memory for the Hurd?
From: |
Neal H Walfield |
Subject: |
Re: Shared-Memory for the Hurd? |
Date: |
Thu, 30 Nov 2000 23:56:49 -0500 |
User-agent: |
Mutt/1.2.5i |
Al right, a lot this is stuff that I am not going to comment on as there
are much better people do do this (e.g. Roland). However, I feel can
make the following comments:
* We do not have a netname server. The hurd's equivalent is the file
system: this is where all ports are advertised. In fact, thinking
about the file system as a file system is inherently flawed: it is
much better to consider it a ``port system.''
Having said that, what's a file? Nothing more than a port managed
by a server waiting for specific messages such as open, seek etc.
(see /include/hurd/io.defs).
So, how does one do non-io operations? The function
file_name_lookup (/include/hurd.h) returns a file_t which happens
to be a perfectly valid port that any type of message can be sent
to (not just io messages; of course, unknown messages will fail,
however, you get the point).
Thus, one could write a, e.g. ``bank server,'' that uses a custom
interface (i.e. a MiG defs file) and settrans it into the file
system. Anyone who has a client that can talk the protocol also
has the ability to use the server.
To conclude, the shm server would live in, e.g. /servers/shm.
Inheriting from libtreefs or libdiskfs seems like a good idea
(enabling you to expose the maps in that directory). Using trivfs
is a bad idea (I did it in my procfs:
ftp://walfield.org/pub/people/neal/hurd/procfs; don't worry, it
will not be going in CVS).
* Getting a task's task port would likely have to be done by
requesting it from the task itself (Correct me if I am wrong,
however, I do not think that it can be requested from anyone except
the task itself; check /include/hurd/process_request.defs).
However, shmat, for instance, is wrapped in a libc function, then
this would be quite transparent.
* Servers normally use many demuxers. That is to say that they may
implement their own interface and use others from libraries are the
same time. For instance:
int
demuxer (mach_msg_header_t *inp,
mach_msg_header_t *outp)
{
int my_server (mach_msg_header_t *, mach_msg_header_t *);
int my_fsys_server (mach_msg_header_t *, mach_msg_header_t *);
int my_io_server (mach_msg_header_t *, mach_msg_header_t *);
return (my_server (inp, outp)
|| my_fsys_demuxer (inp, outp)
|| my_io_demuxer (inp, outp)
|| ports_notify_server (inp, outp)
|| ports_interrupt_server (inp, outp))
}
or using trivfs to handle all of the fsys and io details:
int
demuxer (mach_msg_header_t *inp,
mach_msg_header_t *outp)
{
int trivfs_demuxer (mach_msg_header_t *, mach_msg_header_t *);
int my_server (mach_msg_header_t *, mach_msg_header_t *);
return (my_server (inp, outp)
|| trivfs_demuxer (inp, outp))
}
Here, you are using trivfs and your own interface.
Hope this helps.
Good luck!
-Neal
--
Neal H Walfield
University of Massachusetts at Lowell
neal@walfield.org or neal@cs.uml.edu