flat assembler
Message board for the users of flat assembler.

Index > MenuetOS > suggestion for new system call (re: modems)

Author
Thread Post new topic Reply to topic
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
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):

Exclamation
>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
Exclamation

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:

Exclamation
>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
Exclamation

dunno if those examples were of any use at all Smile
Post 28 Mar 2004, 08:58
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
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
Post 28 Mar 2004, 09:06
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 231
Ville
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)
Post 29 Mar 2004, 08:02
View user's profile Send private message Reply with quote
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
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.
Post 31 Mar 2004, 06:25
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
compilax



Joined: 18 Feb 2004
Posts: 56
compilax
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 Smile )
Post 31 Mar 2004, 08:31
View user's profile Send private message Visit poster's website MSN Messenger Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 231
Ville
Menuet IPC is quite fast and functions like microkernel message passing.
Post 31 Mar 2004, 09:51
View user's profile Send private message Reply with quote
Wishing



Joined: 21 Feb 2004
Posts: 56
Location: NY
Wishing
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.
Post 02 Apr 2004, 04:43
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger ICQ Number Reply with quote
cr_quan



Joined: 30 Jan 2004
Posts: 4
Location: Changsha, China
cr_quan
I just don't like this line:

int 0x41

we use int 0x40, and that's enough.
Post 02 Apr 2004, 05:56
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 231
Ville
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.
Post 02 Apr 2004, 07:22
View user's profile Send private message Reply with quote
spideros1



Joined: 17 Jan 2004
Posts: 77
Location: Poland
spideros1
Ville wrote:
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 Smile 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.
Post 02 Apr 2004, 08:29
View user's profile Send private message Visit poster's website Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 231
Ville
spideros1 wrote:
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.
Post 02 Apr 2004, 11:53
View user's profile Send private message Reply with quote
spideros1



Joined: 17 Jan 2004
Posts: 77
Location: Poland
spideros1
Ville wrote:
spideros1 wrote:
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 Wink Now almost every device can be programmed in user mode, so kernel can be small and stable.
Post 02 Apr 2004, 17:06
View user's profile Send private message Visit poster's website Reply with quote
Ville



Joined: 17 Jun 2003
Posts: 231
Ville
spideros1 wrote:
So I/O problem is solved Wink 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.
Post 03 Apr 2004, 12:24
View user's profile Send private message Reply with quote
Big Moron



Joined: 15 Apr 2004
Posts: 1
Big Moron
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... Razz

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...
Post 15 Apr 2004, 01:08
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.