[jw@ibch01.inf.tu-dresden.de (Wittenberger) writes:]
>... is the port number something like a unique identifier of
>a server, is the name a client knows for it something like a alias or
>more hard coded, is it possible to have different names for the same
>server in different client views?
A port number (type port_name from <sys/types.h>) is indeed a unique
identifier for a server port on a machine running VSTa. In general, a
server allows the kernel to allocate an identifier dynamically, and then
the server advertises itself by creating a file in /namer whose contents is
its port_name. Thus, the "fd" server (floppy disk) might get the value
1027, and then he write "1027" onto /namer/disk/fd. When somebody wants to
talk to the "fd" server, they open /namer/disk/fd, read the number 1027, and
then msg_connect() to port_name 1027.
A very few port_name's are "well known". The /namer server is always 1,
This allows you to connect to /namer initially, otherwise there's the
"chicken and egg" problem of how to find the service which helps you find
services.
>Same as above for the paging mechanism. How is it embedded in the
>system.
First, in the mailing list archives is a fairly detailed discussion of the
VM system data structures.
>- where the decicion is made which page is to swap out or in
>- how the pager is activated
We use the old BSD-style two handed clock algorithm. See the discussion of
this in the book Kirk McKusick put out on BSD internals.
>- where the page is transfered (may be from the kernel?)
The kernel queues the I/O to the swap server. The swap server is
potentially connected to a number of underlying physical devices, looks up
the swap block number, finds out which device and which position that block
lives at, and forwards the request.
This allows the swap server to provide dynamic swap creation and deletion,
interleaved swap, and so forth without any of this complex code living in
the kernel. The kernel just lives in a wonderland of a single swap
partition starting with block 0 and going up to block n-1 (for current swap
size available of n).
>So I propose to *generally* provide the name as a parameter and never
>code it hard. At this time, this is not a great deal, and I think is
>is worth the effort and pay in the future.
I could buy this argument. When we get shared source control on-line I'd
welcome you to commit patches to have all server behave similarly.
>Going further the way from topic 3. Every main of a server will become
>almost equal. It will:
>...
>Why should it remain as a part of code copied for every server?
Well, there are a number of subtle variations. Some need I/O port range
access, some need a couple ranges of I/O ports, some need to connect to
other servers first, some don't. There are also some tricky issues with
startup against an interrupt-driven I/O device. See the mach/wd server
and the "partundef" variable, for instance.
Gavin Nicol has also expressed interest in this area. I think it can be
done, and would be an improvement. But don't be surprised if it's harder
than you expected to map all the nasty little details into a common, shared
routine.
>May be it will be worth to code the server_main loop in a library
>function too.
This has even more subtle variations, since some servers have different
needs for M_ABORT handling, and some have limitations in message segmenting.
>This had the disadvantage, that every server must
>provide a function of the same name for every possible message, even
>when some of them read msg_xxx(msg m, file f){}.
Well, you can have the servers provide pointers to functions instead, with
uninitialized ones being NULL, and your shared server_main code taking
default actions on NULL vectors.
>But it had the
>advantage of not carrying a long almost constant funtion in every
>server.
It's that "almost" contant that will bite you. Again, I think this is a
good idea, but some hard work and thinking would be needed to actually
implement it across all servers. I'd be happy to pitch in if you want to
pursue it!
Regards,
Andy
Received on Thu Aug 11 09:24:51 1994
This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:04:28 PDT