Re: Thoughts for discussion & info request

dave wrote:
>From dave Tue Aug 16 14:29:50 1994
>Subject: Re: Thoughts for discussion & info request
>To: jw@ibch50.inf.tu-dresden.de (Wittenberger)
>Date: Tue, 16 Aug 1994 14:29:50 +0100 (BST)
>In-Reply-To: <9408161058.AA18251@ibch50.inf.tu-dresden.de> from "Wittenberger" at Aug 16, 94 12:58:11 pm
>X-Mailer: ELM [version 2.4 PL23]
>MIME-Version: 1.0
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: 7bit
>Content-Length: 6460
>
>Wittenberger wrote:
>>
>>
>> > Well, after I did some work on the serial and ps/2 mouse code a couple of
>> > months back I think the server handles both 2 and 3 button mice
>> > automatically (it's possible on these 2 types to handle 2 button mice as a
>> > subset of 3 button mice).
>>
>> I think you didn't get what I'm talking about. It is not the problem
>> that you might have 2 and 3 button at the same time. It's a matter of
>> evolution. When you had only 2 button you can only write code for 2
>> button. Period. It's just because you can't know that anybody will
>> ever invent the 3rd button. When the 3rd button is added later you run
>> into the typical problem of needing an update. But with the ability of
>> renaming and aliasing its just a little extention which never affects
>> anything else.
>
>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).
>
>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.
>
>> (Over all, the problem with the mouse is just a example, and because
>> of the fact, that the 3rd button of the mouse is older than VSTa it is
>> no real problem with VSTa. But which example should I chose about
>> things not invented yet?)
>
>The mouse is probably a bad example :-)
>
>> > As for the problem with what we call them, I can see two easy ways to
>> > implement this:
>> >
>> > 1) We could simply call the mouse srv/mouse (as we do now) and use the
>> > FS_WSTAT mechanism to allow the client to specify the mode of operation. As
>> > an example we could define "btnemu" which could take an number of arbitrary
>> > states, say "none", "both_pressed_equals_middle" or "keyboard_key_m". It's
>> > an exagerated example, but I think it gives the general idea.
>>
>> And now the old code would never work, because it dosn't know about
>> the new extention of FS_WSTAT.
>>
>> Or the old behavior is default, then the new code is filled up with
>> unneccessary code for changing the mode. Code which doen't belong to
>> the work it really should do.
>
>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
>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).
>
>I agree however about not wanting to put extra code into a new version of a
>server just to make it work with old code.
>
>> > or we could mount the individual server variant we require and just call it
>> > /dev/mouse.
>> >
>>
>> That is what I'd like. But why mut we be forced to have the services
>> come from only one server?
>
>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)
>
>In fact a lot more of the coding I did on wd, fd and rs232 was to handle
>specification of IRQ/DMA/IO address settings than specification of namer
>pathnames.
>
>> > In this instance I'd have a personal leaning towards solution 1, but there's
>>
>> I think it is because it is the custom, traditional way.
>
>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).
>
>In reality this particular case is more the exception rather than the rule
>as the mouse only handles a single device. In most cases, multiple devices,
>or cases where the behaviour required is not a simple subset of the default
>case would use solution 2. Whilst thinking about this I realised that
>what's actually happened is that any server that wants to be able to serve
>more than a single client at a time has adopted solution 2, and the others
>(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.
>
>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.
>
>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).
>
>> > no good reason that I can point at for this, as with the modified fd server
>> > I've used the second approach to allow the user to specify the media type
>> > in the drive. It's exactly this sort of flexibility in server coding that
>> > makes me prefer VSTa to say Unix (although it did take me a couple of months
>> > to appreciate the benefits).
>>
>> I agree. But the question again, why should we get the benefit from
>> the flexibility after the definiton of the server but not before?
>
>I probably wasn't too clear in what I was saying - I hope I've explained my
>original comments a little better :-)
>
>
> Regards,
> Dave
>
Received on Tue Aug 16 05:55:41 1994