Page 1 of 1

__devices__

Posted: Fri Dec 31, 2004 6:24 am
by intel_breaker
I make diferent device manager. 32 byte packets sends to all devices. Drivers is not pluged to interrupt - are a normal task(ring3). This metod is today slowly.... but i writing most part of algorithms again.
I send part of code soon

Re:__devices__

Posted: Sun Jan 02, 2005 1:21 pm
by intel_breaker
This is my devices supporting code :)
Fix it, if its possible:P

Re:__devices__

Posted: Mon Jan 03, 2005 5:27 am
by Solar
Sorry, but without a hint to what the problem is, it's hard to say anything.

Re:__devices__

Posted: Mon Jan 03, 2005 7:07 am
by Pype.Clicker
i see *much* searching loops in your code. I'm not sure what they're all meant for, and the stuff probably lacks explaination of what the system is supposed to do and how you do it.

Re:__devices__

Posted: Mon Jan 03, 2005 8:33 am
by distantvoices
searching for a free slot in a message queue is definitely quite a waste of cpu time. Why not keeping a pointer to the next *free* slot? Say, you keep a queue of free slots, and simply put slots to this list after popping off the message. (that can be done with a out-pointer.)

But all in all - due to the lack of comments and due to the lack of problem description, we cannot provide you with a solution.

Re:__devices__

Posted: Mon Jan 03, 2005 12:25 pm
by intel_breaker
meabe that:
I sen all system code and description of it, OK?

Re:__devices__

Posted: Mon Jan 03, 2005 12:41 pm
by Pype.Clicker
i don't think more code is needed. What is needed is the *documentation* of the existing code. Eg a description of how those "ports" structure are supposed to be used, what function is supposed to be called when in a general example and things alike ...

Re:__devices__

Posted: Tue Jan 04, 2005 10:05 am
by intel_breaker
/NetOSr0/kernel/devices.c - documentation :)

Ok, NetOSr0 is a short. The full name is New Technology Operating System release 0.
All tasks in scheduler managment are called system_structure_t.

This is the code:

struct system_structure_s
{
/* SYSTEM_STRUCTURE MUST HAVE 900 (+-4) byte! */

tss_t tss;

uint16 gdt_entry;

uint32 pid;

uint8 name[100];


uint8 granularity[596]; /* we sets structure granularities [900 - ... = granularity] */


uint8 reqversion;
uint8 version;


uint8 author[50];
uint8 type; /* is task, driver, anything else ? */

uint8 active;
uint8 enabled;

uint8 privilage; /* 0 - su, 1 - user, 2 - slave */

uint32 begin_adress;
uint32 end_adress;

uint32 buf_in;
uint32 buf_out;

system_structure_t *next; /* for scheduling */
system_structure_t *prev;

uint8 priv_type; /* private system structure type */

uint32 ip_list;
uint32 op_list;
};

Devices driver is represent in system by driver (system_structure_t).
If i want make driver i write in my o.s code for example that:

/************************************************************
system_structure_t *drv;
module_t *drv_module; (for now - modules are only from grub)

drv = craete_driver(drv_module,"Generic keyboard driver"); /* first - module, second - name */
drv -> type = KEYB_DRV; /* (0x21) */
drv -> pid = get_driver_pid(drv); /* 1024 + type_of_driver example: KEYB_DRV_PID = (uint32) 1024 + (uint32) 0x21 */
add_driver(drv);

************************************************************/


Function add_driver(system_structure_t *driver) adds driver to SSDB (System Structures Data Base)
and to SDDB (System Drivers Data Base). This Data Bases are tables in memory with 1024 slots.
Evry Slot has adress of system_structure_t structure. Next, add_driver(...) calling functions
register_user_buffers(...) - this function allocates 2 * 4096 byte for driver buffers (this buffers are
creates with evry structure - task, drivers ...
There are two buffers for every system_structure: input buffer and output buffer.
In input buffer drivers has request from other tasks to execute some functions, tasks has answeres from driver
To the output buffer system structures sends requests for drivers. The ASM (Advanced Syscalls Manager) getting
requests from task output buffer to the driver input buffer. Driver getting request from
input buffer executes request and answered to the output buffer. The ASM getting answer from driver
output buffer and sends it to the task input buffer. If task got answer for request continuing executing code.
The requests are sending in 16KiB packets. Every packets has 4 entry:

1: sending_task_pid
2: value 1
3: value 2
4: value 3

The values are like as registers in real mode.
Example, I'am in user task (ring3) and I would sends putchar('c') request to the terminal driver.

in task code i write that:

putchar('c') :)

but in library this function is defined that:

fill_user_packet(2,'c',0) - first argument sends that function number 2 must be executing for task request.
- second argument has what we want put on screen
- argument number 3 is empty (not used)

send_user_packet(TERM_DRV); /* 0x100 */
i = count_input_answers();
while(i == count_input_answers())
{
}

The task pid adds ASM.
And of course drivers had i/o ports list.
If in driver i/o list is requested port - driver can uses it.

Ok, This work perfectly:) but veryyyyyyy slowly:(
If you have any questions for me - write on [email protected]

Re:__devices__

Posted: Tue Jan 04, 2005 12:36 pm
by distantvoices
you say a message takes 16 KiB? ARe you sure you need that much space for simple communication messages? Then I wouldn't wonder about the slowlyness. Imagine you have to copy around 16 KiB of Data. The poor cpu. :o

Re:__devices__

Posted: Tue Jan 04, 2005 10:49 pm
by Ozguxxx
He can use dma :D.