Re: Thoughts for discussion & info request

Dave wrote:

> I agree - a 4 button mouse would present a problem, in which case having two
> servers would be a reasonable idea, although in practice we could only have
> one loaded at a time as they'd both be trying to control the same hardware
> resource (In fact, the second one would fail during loadup and not run).

Thats why I think VSTa has issues which have to be improved.

> A lot would depend on how important backward compatibility really was to the
> server however, as there are ways that this can be implemented, but I'll
> discuss this in a few lines.

Yes, but thats what everybody needs. Nobody can efford to remake all
systems all the time.

> Well it wouldn't have to be the default mode - it could just be a backward
> compatibility mode. The messaging mechanism means that we can use an

call it as you like it. I don't know whether there is a english version
of the german idiom: "Namen sind Schall und Rauch" (word by word:
Names are noise and dust.)

> arbitrary program to change the mode to whatever we require. When I'm
> working on servers I frequently use the "stat" command as this allows all of
> the stat fields to be read/written (assuming the user has sufficient privs -
> if they haven't then they can't swap server's either so it's a little
> academic).

But it makes lots of things. It makes a system complicate. It forces
me to remember a lot of schemes and other things. But the same can be
made in a simple renaming scheme. And that is more natural, because it
is the way it is done by everyone everyday. It is the way language
works! (BTW: that is why I cam across the issue. I tried to figure
out, why something is called to be "easy to use", "clean" or so. It
is, when is goes the natural way to behave like natural language. Sure
there are technical ways to do it other, but that is why lot of gurus
for special systems exist.)

> Well, at the moment there's the fundamental issue of each server being
> granted interrupts/dma channels at startup with no way of releasing these
> without the server exiting. I have mentioned this to Andy before (I'd
> really like to be able to do this anywhere in the server code as I could
> then do interrupt/dma autoprobing)

I don't know about the details. But at the first glance it looks like
better splitting up the server in servers at first level, which are
started from a server at second level...

> I think I mentioned yesterday that I think the real reason was that of the
> two possibilities I mentioned, the first one involved less code (and thus
> less liklihood of bugs).

I disagree. The 1st solution needs special code. The second need some
arguments at startup, which can be handled in a uniform way.

> (eg the mouse) have adopted solution 1. I think this also emphasises the
> comment I made about using the solution that matches the complexity of the
> service being provided.

From the server view you are right. At least at the first moment, when
no further development exists. But the server are there to be an
abstraction level. When most servers are abstractions (that means
here, they don't know about their context, i.e. name) and some not,
the level above has to handle with more complexity.

> As an example when I modified the rs232 server I continued to use solution 1
> as this meets the requirements well for a single UART - if there are 2 UARTs
> we use two servers (shared code pages are wonderful!). I considered
> extending the server to allow multiport boards to work, but rejected this as
> it added a lot of complexity to have to deal with the different ways the
> boards would need to handle interrupts, etc. What I decided was that if I
> wanted to use a multiport board I'd write a server specifically for the
> task, giving me the simplest solution for both types of hardware - the
> multiport implementation would use solution 2 however as a different process
> might want to comunicate with each port.

In my mind that is really the one and only way. But you would never
had to think about the issue, when the let call it primitiv first
solution wouldn't have been there.

By the way, I still can't figure out, why the dynamic named approach
would need more code than the hard wired + FS_STAT.

> FWIW (and why I think the mouse was perhaps not an ideal example) I actually
> wanted to split the mouse server up - creating a "libmouse" for all of the
> common code and separate servers for the ps/2, rs232, microsoft bus and
> logitech bus mice. Having the rs232 mouse in there particularly bothers me
> still as it now relies on an rs232 server whereas the others don't need
> anything else. When I get some time I may still do this in fact, as it
> would be nice to make the rs232 mouse code system independent (for example I
> have an old Sun serial mouse that works fine on a PC's serial port).

Ok, the mouse is not really the best example, It just one I cam
accross in practice and on another system.
In my mind, there should be x different servers. Each build from a
common library on the mouse and some files special to the particular
one to handle. At startup I'd like to select the one I wont to use and
give it the name I like.

This would allow me a flexibility I could never think of in
traditional systems. Imagine I load 2 mouse servers, connect to
devices and know I have 2. Sure nobody will use this. Really? No!
Nobody can have it, traditionally. But imagine someone would have it.
He may write a game for 2 people.

For your problem with the rs232 mouse: I can't understand your
problem. It is just the most natural solution I can think of.
Why the hell should the rs232 code be duplicated in a second server?
It's wasted work. (For me: I would never use a rs232 mouse server which
is concurrent to the rs232 device server. I find this idea confusing.
And I can imaging great trouble from this.) There is no good reason to
have something independent from something else what is on a level
closer to the hardware.

/joerg
Received on Tue Aug 16 07:23:03 1994