tempos-project-list Mailing List for TempOS
Brought to you by:
renepinto
Menu
▾
▴
tempos-project-list — Mail list of TempOS project, for users and developers
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Diogo F. S. R. <dio...@gm...> - 2009-07-11 00:54:36
|
On Fri, Jul 10, 2009 at 8:55 PM, Renê<re...@re...> wrote: > You are working on IA-64 port, that's your decision, do it in the way > you think you should do... IMHO replicating all the x86 tree it's no > so bad, because the structure are the same (in IA-64), although I know > there are reasonable changes... It's the same, and that is the problem. The differences are actually assembly differences. As operands sizes and stuff. But that's ok. I resigned myself and will think about it when I finish the port. You said that some shellscripts could do the trick about integrating the different parts. After I finish it we could talk again about it. -- Diogo F. S. Ramos |
|
From: Renê <re...@re...> - 2009-07-11 00:02:50
|
You are working on IA-64 port, that's your decision, do it in the way you think you should do... IMHO replicating all the x86 tree it's no so bad, because the structure are the same (in IA-64), although I know there are reasonable changes... Cheers; Renê On Fri, Jul 10, 2009 at 5:02 PM, Diogo F. S. Ramos<dio...@gm...> wrote: > I am questioning myself if replicating all the x86 tree and then > making the adjustments in the x86_64 tree is the right way to make the > 64 bits port. > > As the transition is going on I am getting my hands dirty and getting > the hang of the OS, and that is good. Maybe just that is a good reason > to do it the way I am doing it. But the idea of duplicating work is > not quite satisfying. > > -- > Diogo F. S. Ramos > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Tempos-project-list mailing list > Tem...@li... > https://lists.sourceforge.net/lists/listinfo/tempos-project-list > |
|
From: Diogo F. S. R. <dio...@gm...> - 2009-07-10 20:02:47
|
I am questioning myself if replicating all the x86 tree and then making the adjustments in the x86_64 tree is the right way to make the 64 bits port. As the transition is going on I am getting my hands dirty and getting the hang of the OS, and that is good. Maybe just that is a good reason to do it the way I am doing it. But the idea of duplicating work is not quite satisfying. -- Diogo F. S. Ramos |
|
From: Diogo F. S. R. <dio...@gm...> - 2009-07-10 20:02:44
|
I am questioning myself if replicating all the x86 tree and then making the adjustments in the x86_64 tree is the right way to make the 64 bits port. As the transition is going on I am getting my hands dirty and getting the hang of the OS, and that is good. Maybe just that is a good reason to do it the way I am doing it. But the idea of duplicating work is not quite satisfying. -- Diogo F. S. Ramos |
|
From: Diogo F. S. R. <dio...@gm...> - 2009-07-07 11:53:51
|
On Mon, Jul 6, 2009 at 10:09 PM, Renê<re...@re...> wrote:
> Sure there is a reason.... the structure of GDT has 4 bytes (32 bits),
Actually, I would argue that GDT has more than 4 bytes. I don't know
what exactly GDT you are talking about but neither of them inside
gtd.h has 4 bytes.
The one that I've shown in the last e-mail have 48 bytes.
>> And here gtd_table.gdt_ptr is defined as an uint32_t:
>>
>> struct _gdt_gdtr {
>> uint16_t table_limit;
>> uint32_t gdt_ptr;
>> } __attribute__ ((packed)) GDTR;
> so on IA-32 architecture I use uint32_t... but you can change this if
> you are on other architecture... just define (or change) the type that
> you need on include/unistd.h
>
> Notice, void on IA-32 has 32 bits, but in IA-64 has 64 bits! So simple
> change uint32_t to void can make a really mess on the system!!!
>
> But, we can talk about other ways of do portable code in TempOS....
I think one of us is misinterpreting something. We are talking about
pointers, right? I am aware of the sizes of pointers in 32 and 64 bit
machines. The fact that one declare a pointer as, for example, int *,
is just a hint - or maybe a help - for the preprocessor - maybe for
the compiler too?. It says nothing about the actual size of the
pointer, because it is 32 bits for x86 and 64 bits for x86_64. Now, if
you pass over the preprocessor-compiler and try to use a int (32 bits)
to store your pointers values because you know the size of them, I
think you are just asking for trouble. And for nothing.
Again, I could be looking at the wrong angle at this.
--
Diogo F. S. Ramos
|
|
From: Renê <re...@re...> - 2009-07-07 01:09:29
|
Sure there is a reason.... the structure of GDT has 4 bytes (32 bits),
so on IA-32 architecture I use uint32_t... but you can change this if
you are on other architecture... just define (or change) the type that
you need on include/unistd.h
Notice, void on IA-32 has 32 bits, but in IA-64 has 64 bits! So simple
change uint32_t to void can make a really mess on the system!!!
But, we can talk about other ways of do portable code in TempOS....
Cheers;
Renê
On Sat, Jul 4, 2009 at 5:58 PM, <dio...@gm...> wrote:
> Is there a reason for the pointers to be casted to uint32_t or could
> they just be void *?
>
> Here we see this kind of cast:
>
> GDTR.gdt_ptr = (uint32_t)gdt_table;
>
> And here gtd_table.gdt_ptr is defined as an uint32_t:
>
> struct _gdt_gdtr {
> uint16_t table_limit;
> uint32_t gdt_ptr;
> } __attribute__ ((packed)) GDTR;
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Tempos-project-list mailing list
> Tem...@li...
> https://lists.sourceforge.net/lists/listinfo/tempos-project-list
>
|
|
From: <dio...@gm...> - 2009-07-04 20:58:31
|
Is there a reason for the pointers to be casted to uint32_t or could
they just be void *?
Here we see this kind of cast:
GDTR.gdt_ptr = (uint32_t)gdt_table;
And here gtd_table.gdt_ptr is defined as an uint32_t:
struct _gdt_gdtr {
uint16_t table_limit;
uint32_t gdt_ptr;
} __attribute__ ((packed)) GDTR;
|
|
From: Renê <re...@re...> - 2009-06-23 04:18:41
|
I tried:
# find . -type f -name "*.[chS]" | xargs wc -l | sort -g
31 ./kernel/execve.c
31 ./kernel/fork.c
31 ./kernel/read.c
33 ./kernel/exit.c
34 ./include/tempos/error.h
36 ./include/stdlib.h
36 ./include/tempos/timer.h
38 ./kernel/syscall.c
41 ./include/unistd.h
42 ./include/tempos/syscall.h
43 ./arch/x86/kernel/i82C54.c
43 ./include/ctype.h
46 ./kernel/write.c
47 ./arch/x86/boot/video.h
51 ./drivers/block/ide_generic.c
52 ./arch/include/x86/page.h
52 ./include/tempos/jiffies.h
53 ./arch/include/x86/karch.h
55 ./arch/include/x86/x86.h
56 ./arch/include/x86/io.h
56 ./lib/stdlib.c
59 ./include/linkedl.h
66 ./kernel/timer.c
67 ./arch/include/x86/i8259A.h
68 ./arch/include/x86/i82C54.h
71 ./arch/include/x86/exceptions.h
71 ./arch/include/x86/mm.h
72 ./include/string.h
76 ./arch/x86/kernel/sys_enter.S
79 ./include/tempos/mm.h
83 ./arch/include/x86/irq.h
83 ./include/drv/i8042.h
98 ./kernel/mm/init_mm.c
99 ./arch/x86/io.c
100 ./include/tempos/kernel.h
110 ./arch/include/x86/idt.h
110 ./kernel/kernel.c
112 ./lib/ctype.c
123 ./arch/x86/boot/boot.S
124 ./arch/x86/kernel/i8259A.c
126 ./arch/x86/exceptions.c
133 ./lib/string.c
135 ./lib/linkedl.c
142 ./arch/include/x86/multiboot.h
150 ./arch/include/x86/gdt.h
150 ./arch/x86/boot/karch.c
157 ./arch/x86/kernel/irq.c
165 ./arch/x86/boot/video.c
173 ./arch/x86/gdt.c
191 ./arch/x86/idt.c
221 ./kernel/mm/kmalloc.c
240 ./drivers/char/i8042.c
296 ./arch/x86/isr.S
305 ./lib/printf.c
310 ./arch/x86/mm/mm.c
5472 total
Yeah!!! memory manager wins! 5472 lines of code (with comments and
spaces), not so bad....
Cheers;
Renê
|
|
From: Renê <re...@re...> - 2009-06-23 03:32:27
|
Okay, Now we have a decent Build System :-) The Makefile and Build's.mk was completely rewritten. There are dependencies generation (inclusive with header files, what it's very important and useful), and without recursive Makefiles (sorry Didi, I know you like that, unlike me...). I was taking a look in Linux Kbuild.... really, it's to much for us now, TempOS is an small OS and the current Makefiles are good enough. Cheers; Renê |
|
From: Renê <re...@re...> - 2009-06-22 03:44:33
|
I share the same opinion... we need a robust build system, and that is why I thought in Kbuild. But we can discuss another possibilities.... ever... Cheers; Renê On Sun, Jun 21, 2009 at 10:27 PM, Diogo F. S. Ramos<dio...@gm...> wrote: > On Sun, Jun 21, 2009 at 10:25 PM, Diogo F. S. Ramos<dio...@gm...> wrote: >> Did you take a look at kbuild? I still think that some sort of build >> system will pay off later. > > But thinking a little more (30 seconds?) I think I am just nitpicking. > Maybe it's because my personal problems with hand made Makefiles. > > > -- > Diogo F. S. Ramos > > ------------------------------------------------------------------------------ > Are you an open source citizen? Join us for the Open Source Bridge conference! > Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. > Need another reason to go? 24-hour hacker lounge. Register today! > http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org > _______________________________________________ > Tempos-project-list mailing list > Tem...@li... > https://lists.sourceforge.net/lists/listinfo/tempos-project-list > |
|
From: Diogo F. S. R. <dio...@gm...> - 2009-06-22 01:27:37
|
On Sun, Jun 21, 2009 at 10:25 PM, Diogo F. S. Ramos<dio...@gm...> wrote: > Did you take a look at kbuild? I still think that some sort of build > system will pay off later. But thinking a little more (30 seconds?) I think I am just nitpicking. Maybe it's because my personal problems with hand made Makefiles. -- Diogo F. S. Ramos |
|
From: Diogo F. S. R. <dio...@gm...> - 2009-06-22 01:25:45
|
On Sun, Jun 21, 2009 at 10:11 PM, Renê<re...@re...> wrote: > Features working on: > > - File system (Renê working on) > - Proccess control and scheduler (Renê working on) > - IDE controller driver (Renê working on) > - Port to IA-64 (Intel 64 bits) architecture (Didi working on) OH YEAH! ;-) Did you take a look at kbuild? I still think that some sort of build system will pay off later. -- Diogo F. S. Ramos |
|
From: Renê <re...@re...> - 2009-06-22 01:11:24
|
Features working on: - File system (Renê working on) - Proccess control and scheduler (Renê working on) - IDE controller driver (Renê working on) - Port to IA-64 (Intel 64 bits) architecture (Didi working on) Features not implemented (and required with some urgency) - Console API - Framebuffer (VESA to text mode) driver - Serial driver - PCI API - Device drivers API - Device drivers (for other hardwares) - Network stack - POSIX syscalls - Port libc (or newlib) to TempOS With these features TempOS will run a lot things, like gcc, bash, and posix tools... Cheers; Renê |
|
From: Renê <re...@re...> - 2009-06-17 01:21:05
|
Legal Didi, só deixei um pouco mais genérico. Por favor, teste na sua máquina. Quanto aos ponteiros, olhe o arquivo include/unistd.h, lá tem os tipos declarados ulong32_t, etc... t+! Renê Que tal o primeiro patch? Fiz duas minúsculas alterações no Makefile para compilar em uma arquitetura 64 bits (cross-compile ?) o código para arquitetura 32 bits. O patch eu gerei dando: git format-patch origin Espero que tenha sido gerado corretamente. Primeira vez que faço isso. :-D 2009/6/16 Diogo F. S. Ramos <diogofsr@gm...>: > (Vou escrever em português, como você disse no e-mail. Assim que você > achar melhor, mudamos para o inglês). > > Então, como a entrada lá no tracker mostra, estou tentando compilar > aqui em casa o tempos num Ubuntu 9.04 64 bits. > > Todos os erros (e warnings) que estão dando aparentemente são mesmo > porque aqui é 64 bits. Alguns me parecem ser mais fáceis de arrumar > que outros (mas não posso afirmar, pois não sei quanto dependente de > implementação são as chamadas.). Vamos aos poucos. Primeiro os > warnings. > > Todos eles vem ou do "arch/x86/idt.c" ou do "/arch/x86/gdt.c" (um só > deste aqui) e são relacionados ao tamanHo de ponteiro. Um exemplo: > > arch/x86/gdt.c:152: warning: cast from pointer to integer of different size > > E a linha correspondente: > > GDTR.gdt_ptr = (uint32_t)gdt_table; > > Apesar de possuírem o mesmo warning as outras linhas não são tão > claras como essa mas, a julgar por esta, o tempos assume que um > ponteiro tem 32 bits, o que não é verdade para uma plataforma 64 bits. > Os casts podem ser alterados para algo mais genérico do que um > ponteiro inteiro? > > Quanto aos erros, seguem alguns: > > arch/x86/isr.S: Assembler messages: > arch/x86/isr.S:52: Error: suffix or operands invalid for `push' > arch/x86/isr.S:53: Error: suffix or operands invalid for `push' > arch/x86/isr.S:54: Error: suffix or operands invalid for `push' > arch/x86/isr.S:55: Error: suffix or operands invalid for `push' > arch/x86/isr.S:56: Error: suffix or operands invalid for `push' > arch/x86/isr.S:57: Error: suffix or operands invalid for `push' > arch/x86/isr.S:58: Error: suffix or operands invalid for `push' > arch/x86/isr.S:59: Error: suffix or operands invalid for `push' > > Estes eu acho que darão mais dor de cabeça. Aparentemente o sufixo "l" > não existe na plataforma 64 bits, sendo um comando 32 bits. É possível > utilizar uma chamada mais genérica que o pushl (perceba minha total > ignorância quanto ao assunto) ou a solução seria adicionar lindos > #ifdefs? > > -- > Diogo F. S. Ramos > -- Diogo F. S. Ramos |
|
From: Diogo F. S. R. <dio...@gm...> - 2009-06-16 07:33:04
|
Que tal o primeiro patch? Fiz duas minúsculas alterações no Makefile para compilar em uma arquitetura 64 bits (cross-compile ?) o código para arquitetura 32 bits. O patch eu gerei dando: git format-patch origin Espero que tenha sido gerado corretamente. Primeira vez que faço isso. :-D 2009/6/16 Diogo F. S. Ramos <dio...@gm...>: > (Vou escrever em português, como você disse no e-mail. Assim que você > achar melhor, mudamos para o inglês). > > Então, como a entrada lá no tracker mostra, estou tentando compilar > aqui em casa o tempos num Ubuntu 9.04 64 bits. > > Todos os erros (e warnings) que estão dando aparentemente são mesmo > porque aqui é 64 bits. Alguns me parecem ser mais fáceis de arrumar > que outros (mas não posso afirmar, pois não sei quanto dependente de > implementação são as chamadas.). Vamos aos poucos. Primeiro os > warnings. > > Todos eles vem ou do "arch/x86/idt.c" ou do "/arch/x86/gdt.c" (um só > deste aqui) e são relacionados ao tamanHo de ponteiro. Um exemplo: > > arch/x86/gdt.c:152: warning: cast from pointer to integer of different size > > E a linha correspondente: > > GDTR.gdt_ptr = (uint32_t)gdt_table; > > Apesar de possuírem o mesmo warning as outras linhas não são tão > claras como essa mas, a julgar por esta, o tempos assume que um > ponteiro tem 32 bits, o que não é verdade para uma plataforma 64 bits. > Os casts podem ser alterados para algo mais genérico do que um > ponteiro inteiro? > > Quanto aos erros, seguem alguns: > > arch/x86/isr.S: Assembler messages: > arch/x86/isr.S:52: Error: suffix or operands invalid for `push' > arch/x86/isr.S:53: Error: suffix or operands invalid for `push' > arch/x86/isr.S:54: Error: suffix or operands invalid for `push' > arch/x86/isr.S:55: Error: suffix or operands invalid for `push' > arch/x86/isr.S:56: Error: suffix or operands invalid for `push' > arch/x86/isr.S:57: Error: suffix or operands invalid for `push' > arch/x86/isr.S:58: Error: suffix or operands invalid for `push' > arch/x86/isr.S:59: Error: suffix or operands invalid for `push' > > Estes eu acho que darão mais dor de cabeça. Aparentemente o sufixo "l" > não existe na plataforma 64 bits, sendo um comando 32 bits. É possível > utilizar uma chamada mais genérica que o pushl (perceba minha total > ignorância quanto ao assunto) ou a solução seria adicionar lindos > #ifdefs? > > -- > Diogo F. S. Ramos > -- Diogo F. S. Ramos |
|
From: Diogo F. S. R. <dio...@gm...> - 2009-06-16 04:50:23
|
(Vou escrever em português, como você disse no e-mail. Assim que você achar melhor, mudamos para o inglês). Então, como a entrada lá no tracker mostra, estou tentando compilar aqui em casa o tempos num Ubuntu 9.04 64 bits. Todos os erros (e warnings) que estão dando aparentemente são mesmo porque aqui é 64 bits. Alguns me parecem ser mais fáceis de arrumar que outros (mas não posso afirmar, pois não sei quanto dependente de implementação são as chamadas.). Vamos aos poucos. Primeiro os warnings. Todos eles vem ou do "arch/x86/idt.c" ou do "/arch/x86/gdt.c" (um só deste aqui) e são relacionados ao tamanHo de ponteiro. Um exemplo: arch/x86/gdt.c:152: warning: cast from pointer to integer of different size E a linha correspondente: GDTR.gdt_ptr = (uint32_t)gdt_table; Apesar de possuírem o mesmo warning as outras linhas não são tão claras como essa mas, a julgar por esta, o tempos assume que um ponteiro tem 32 bits, o que não é verdade para uma plataforma 64 bits. Os casts podem ser alterados para algo mais genérico do que um ponteiro inteiro? Quanto aos erros, seguem alguns: arch/x86/isr.S: Assembler messages: arch/x86/isr.S:52: Error: suffix or operands invalid for `push' arch/x86/isr.S:53: Error: suffix or operands invalid for `push' arch/x86/isr.S:54: Error: suffix or operands invalid for `push' arch/x86/isr.S:55: Error: suffix or operands invalid for `push' arch/x86/isr.S:56: Error: suffix or operands invalid for `push' arch/x86/isr.S:57: Error: suffix or operands invalid for `push' arch/x86/isr.S:58: Error: suffix or operands invalid for `push' arch/x86/isr.S:59: Error: suffix or operands invalid for `push' Estes eu acho que darão mais dor de cabeça. Aparentemente o sufixo "l" não existe na plataforma 64 bits, sendo um comando 32 bits. É possível utilizar uma chamada mais genérica que o pushl (perceba minha total ignorância quanto ao assunto) ou a solução seria adicionar lindos #ifdefs? -- Diogo F. S. Ramos |
