Re: Maybe we should stop "Paging Beth Stone" already...


Richard Cooper wrote:

| > My OS already decodes everything when a key is hit and put this info
| > into a global structure and into a buffer if configured that way.
| >
| > What else would be needed ?

| Plug a second keyboard into your PS/2 mouse port, then tell me what's
| needed to utilize it in your OS. Can it be set up from userland, or do
| you have to modify the kernel or the drivers?

If you can find a free plug for a second keyboard on your PC
my OS would at least recognise it, even not support it :)


| I In mine, the kernel would have a PS/2 port driver, which would export two |
IPC devices, one for each PS/2 port. So normally, you'd load a keyboard
| driver which attaches to the first PS/2 port, and a mouse driver which
| attaches to the second PS/2 port. So if you plugged a keyboard into the
| second PS/2 port, all you would have to do is unload the mouse driver, and
| load a second keyboard driver, telling it to use the second PS/2 port
| instead of the first. Since the IPC protocol it uses to connect to the
| second PS/2 port is identical to the IPC protocol it uses to connect to
| the first PS/2 port (and indeed, identical to the IPC protocol it would
| use to connect to anything and everything), it will happily connect to it
| instead. So that's it, that's all you have to do to get the OS to support
| the second keyboard.

PS/2 ports,(MCA mouse over keyboard) hardware don't work as you expect,
it got nothing to do at all with the software IPC abstaction ...
KEYBD and MOUSY are two independend devices, even they may share one controller.
[...]

| > OS post-development in user-space ? :)
| > Much better is an OS who already does what and how we want it.

| That assumes that you can predict the future. You never know what you
| will want to do tomorrow.

Yes. But I feel free to create a new version of my OS every morning :)
That's what I offer to my clients: indiviual design/adapt/configure/...
on demand and as desired.

| I myself think that things should be done one way one day, and no matter
| how sure I was that I had the best idea for how they should be done, it's
| always possible the next day that I either find something wrong with my
| previous idea, or at least come up with a better idea. So I thought I'd
| design a system where changing things is easy, that way it never has to
| get stuck doing things one way simply because that's the best idea I had
| when I designed the system.

I always check and doubt my own things, as this seems to be the only
way to finally make a product safe enough to sell ...
and be sure, all code I ever sold until today is double cross checked
against all odds and I'm for sure the worst of all examinators when it
comes to prove for a final release.
Perhaps this is why my products are that expensive compared to M$-***.

| > | So in my OS, you'd have a keyboard port, mouse port, and video card |
| > driver which just did the actual hardware interfacing, and nothing| else.
| >
| > Now here (in the hardware section) while in PL0 can be already done
| > a lot of useful things, saving the user from libraries and detours.
|
| Yes, but I'd rather not be saved from those things.

So what,
make it part of the OS-kernel (fast and neat to handle), or
let the user make it his own way (where is the next free bucket ?)

| > | Then I'd have a program that I would call the multiplexer,
| > | which connects to the keyboard and mouse drivers,
| > | and the video card driver.
| >
| > ?? I don't need a multiplexer to display the mouse, the IRQ12(or
| > IRQ3,4,10,11) does this on its own if enabled. If taskchanges then just
| > the mouse's image may be updated, and if there
| > is only one mouse (I can have up to three), then only one global
| > structure (x,y,dx,dy,r/m/l-button and some more) is needed.
| > So the active thread can read it anytime without a task switch.
|
| The multiplexer is designed to provide a generic interface, so it doesn't
| make any assumptions about how the mouse or any other hardware will be
| used by the applications. Instead, it simply performs the task of making
| a single display, keyboard and mouse appear to be many different displays,
| keyboards and mice. That's where it fits into the design, so that's all
| that it does.
|
| Certainly things would be faster if the mouse driver drew directly to the
| screen, but that requires the mouse driver to know about the screen, and
| that's not what I want.

But that's what I do. And I'd recommend this method for many reasons.
It is that easy to set all mousy/keybd-limits/ranges on a Vmode change
that I never needed to think about anymore.

| I want total configurability, so that if I feel
| so inclined I can do something as rediculous as have a mouse attached to
| computer #1 and run the mouse driver on that computer, and run the mouse
| driver's data over a TCP connection to computer #2 and use the mouse on
| computer #1 with computer #2's display, without having the mouse's cursor
| fail to appear because the mouse driver is drawing the cursor to computer
| #1's display.

Remote Mice ?
NO. I'd call an exterminator as of immediate :)


| In my OS, the mouse driver would simply read from whatever device it was
| told to read from, and take whatever mouse protocol the mouse uses and
| convert it to the standard mouse protocol used by the OS. Aside from
| that, it wouldn't do anything else.

Yes. But I can't undersand your previous statment.
Ok, you said "from whatever device" A mouse is a MOUSE what else ?

| > I wouldn't direct connect the user to the hardware section, just making
| > the IRQ-result structs global accessible for all user threads may do it.
|
| Huh? I don't see how that applies to what it was in reply to.

Maybe my brain was out of context this time, but valid for me anyway.


| (BTW, is my computer really wrapping text that poorly, or is that
| something on your end? I can't tell because if the text isn't quoted then
| apparently Opera goes and unwraps it so that it can rewrap it to fit the
| width of the window, so I only see the wrapping when I see other people
| quoting me.)

Actually I adjusted my window-size to not auto-wrap your line size here,
but I can't tell how this affects google.news or yahoo NG-messages.


| > I'm not familiar with abstract layers, for me every piece of hardware
| > has to be treated as it needs to and all hardware drivers are connected
| > via (user shared if granted) structures (including buffer pointers)
| > to communicate with any software.
| >
| > Yes, the above I'd assume to be 'user-system' stuff,
| > except I have no idea what this IPC actually does :)

| IPC is inter-process communication.

| I didn't get all of the details ironed out in my design before I decided
| to do something else, but basically there is a function to tell the kernel
| that you want to offer a service via IPC, and then there's a function to
| tell the kernel you want to connect to some other process' IPC service,
| and then there are functions to do the actual inter-process communication.

I can't get the clue of it, (perhaps this belongs to HLL-world only).

If I (the OS) know about a HW-device which can/may transfer data
to media/serial./parallel/../net/LAN/... then I (the OS) will do it.

Why do I need something abstract (=non existing, but detouring)
to tell my PC that I like to transfer data from one devicee to another ???

| The IPC just does basic communications, it can do stream or block access
.....
I never understood this HLL-concepts of hardware treatment...

If a device is able to receive/send/.. a block of data rather than single
bits or bytes then you (and the rest of the world) will call it a block-
device regardless if I/O,DMA,ADMA,UDMA.SCSI,serial-I/O/p2p ...?
I see devices like sound/Inet/modem/LAN/LPTn/COMn as 'block-transfer-able'
ones, but HD/FD/CD differ to them as the block size isn't variable there.

[..]
> I see it dangerous to let a user play with FileSystem-internals...

| It's perfectly safe as long as they know what they're doing. ....

Aha.
Now I'm totally confused with your demand for full protection on one side,
and the full risk of let the user destroy the FS and write to I/O-ports.

I think my KESYS is on the correct side for avoiding useless protection
detours and making all things less complicated,
the result will be identical, but achieved or crashed much faster :)

__
wolfgang



.