I think somebody should add a driver in the kernel for modems.
heres what i was thinking:
* new syscall - connect, disconect, connect to custom service (load a file with ph number, passwd, etc.)
* add to device setup - COM port, default number/passwd/username/etc. and driver
* can load custom driver if not a standard/old style modem

Its probably better to have a full device management ability like other OSes. im not sure how win/lnx do it, but heres how i'd imagine would be a good way:

add an interupt (0x41?) dedicated to drivers. function 0 is used to find the function number for a device, eg (in the app using the driver):


>devname db 'MODEM ' ; type of device it wants
>devfunc dd 0 ; it's function number
>
>findmodem:
> mov eax, 0 ; function 0 - find device
> mov ebx, devname ; where to find the name
> int 0x41 ; look!
> mov [devfunc], eax ; remember it's function number
> ret


and the kernel will search through a list of drivers and either:
pick the first/last entry named 'MODEM '
or:
open up a window and ask the user what driver to use
then return it's number in eax.

each app would need to know how to use that driver, eg:


>connect_modem:
> mov eax, [devfunc] ; the modem's function number
> mov ebx, 1 ; connect
> mov ecx, usname ; user name
> mov edx, passwd ; password
> mov esi, phnum ; phone number
> int 0x41
> ret


dunno if those examples were of any use at all

I like it... the idea.. as far as code wise.. im atta loss.. but this.. continually having to recompile drives INTO the kernal is.. well GOING to become extremely limited and unfriendly.
Wishing

In Menuet, you can already write device drivers outside the kernel to the application space. The driver application communicates with the device and general applications communicate with the driver app.

So it's already implemented. See system functions 41-46 and 60.

(device) <-syscall-> (driver app) <-ipc-> (general applications)

Sounds exactly like what you didnt want to do in the first place Ville.
It adds layers to the system, puts more things for each programer to cut through to amke work effieciently? Couldnt the kernal some how import the code from a file? ipc seems like a very inneficient way to relay data... especially for something like a data communications device driver... say like a USB driver. Would you really want to send USB comunications through ipc text? Thats like using windows messaging system to transfer data...
I hate to criticize so harshly... i just got a bad feeling about this.

And the current way is better... how?
Wouldnt ints be much faster for things where data can fit in a few words?
it'd be a fair bit more profesional - people would feel less encouraged to put drivers inside the app that uses them and rather put it seperate so it can be used by all apps.
Also would cause less m$ style clutter (you cant disable a certain driver if you cant work out what is and isnt a driver to start with) and if there was such thing as a driver in MeOS - not just the ability to directly handle hardware - people would actualy write drivers.

I like the way linux drivers/modules work - needs aproval by root (therefore requiring a more secure system) to run, and is linked to the kernel so it is like compiling a custom kernel - everything just works like it is the kernel. I like this because you can override the kernel's print function with your own (i'd imagine X does this).

It would create more layers in the way that it is splitting apps into two groups - but it would reduce bugs in actual programs, and how long can you go around making kettles and blenders from the same parts? (my own analogy... prolly doesnt make sense to those back on earth though )

Menuet IPC is quite fast and functions like microkernel message passing.

Yes... thats all nice and true... but you quote it yourself Ville

"...since the idea has been to remove the extra layers between different parts of software, which complicate programming and create bugs."

And I whole heartedly agree with you. Layers are bad... why have two programs running, making the system run 1000's of extra lines of code to keep the 'driver' running, when the drive could be a module that can plug into the kernal. IPC may seem fast for sending a few bits... like error messages (windows does this) but not to transfer a 5 meg mp3 file...

Maybe a specific type of special file should be made for drivers... one that is compiled.. but isnt an executable. One that the kernal could call upon to run and do things, but isnt an extra process itself. It would be dorment while not in use (it would take up mem... but very little) and then active when it needed to be.

Windows and other OS's have theses things, called DLL's
Except windows DLL's can be drivers.. software parts... most anything.. thats why you cant tell what a driver is or isnt.

Could the kernal take a compiled set of functions, which by themselevs arent a full program, and set them someplace special in memory? (shared mem is kinda bad, aka win98) or plop them atop executables in memory that need them? (win xp does something like this)
Im not sure.. these are all my opinions... im also assuming alot as well.. but hopefully some of this makes some sense.

I just don't like this line:

int 0x41

we use int 0x40, and that's enough.

Menuet IPC is a bit different from Windows. I ran a test for transferring two 5 Megabyte data chunks between two processes. Both processes sent 1000 ipc messages ( A -> B, B -> A, A -> B .. ) at the size of 5000 bytes . The double 5 Mb transfer took 0.11 seconds in a 700 mhz laptop.

> And I whole heartedly agree with you. Layers are bad... why have two
> programs running, making the system run 1000's of extra lines of code
> to keep the 'driver' running, when the drive could be a module that can
> plug into the kernal.

Thats actually where Menuet multitasking principle steps in. If a process has no input, then it takes a very small amount of CPU cycles.

That was fast. This could even handle fast SCSI drives I think the problem here is that you can't do I/O directly from/to device without using system call that slows it down. Maybe I/O permission bitmap in TSS would be better, you could use the same interface for reserving I/O space and kernel would simply set/clear bits in I/O bitmap when you reserve/release region, so when 1 driver uses some I/O port area, the others can't use it.

Good idea. I ran a test a minute ago with the new TSS and IO bitmaps and it worked fine. Lets see what turns out.

So I/O problem is solved Now almost every device can be programmed in user mode, so kernel can be small and stable.

You can access ports directly from application with pre 5.1. Set the port area with system function 46 at the beginning of the program.
The pre version also has rd2hd.

wow... am amaze...

The way that menuet goes is impresive, having keept track of this OS for a good long wile, and reading this forum I can see the great efort that it is been put in to it... reading about in the forum I see you peaple are really bright... ... well most of you are, am not to bright in this field I feel...

Sadly, I am not able to get in to programing at the moment, I understand many aspects of it but have only toched COBOL and QBasic... University stiye... (really lame) which means I can bearly create anythig... much less try ASAM ... though I would like to learn... and help out... ... but I am havig a hard time learning since am not focused yet in somethig (be it one programming language or an other)... akk... silly me. Game programer wana be...

Anyhow... Great work guys...
Lets see if I can become helpfull in the future!

This os keeps on getting more an more funktional... Menuet OS 1.0 ... can't be that far of... well ok it migth... When will v 0.76 final be avaible?

Oh... and... good forum...