What are we doing?
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
What are we doing?
I mostly just was interested.
Describe your project maybe?
-JL
Describe your project maybe?
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Working alone. I have never been taught how to program and would not inflict my [probably] dire coding practices on a team .
Project description? Initially an x86_64 kernel and associated boot loader which I am concurrently developing for 32 bit, to test the robustness of the separation of my architecture dependent and independent code. I have thought about trying an 8 bit AVR version too, but that may be pushing it a bit!
Because the kernel was taking so much time, I have started concentrating more on the boot loader (CBoot). Version 1 required GRUB, and then relocated the kernel, set up paging and a sensible GDT, switched VESA mode and set up a physical memory stack. It also has a debug console for pausing kernel loading, switching VESA mode, examining the kernel binary etc... A stack is set up, Argc and Argv are passed to the kernel which is called at its correct entry point, meaning no ASM stub. All of this is customisable based on GRUB command line parameters.
For version 2 (my current active project), I am hoping to achieve this without GRUB and make it more versatile so that others can benefit from the boot loader too (without the use of anything which is GPL'd). Version 2 will also export a unified list of hardware on various busses on the machine. Currently I only support FAT, but hope to add support for at least Ext2/3, ISO9660 and possibly in the far future, network booting. Unfortunately, all this means the kernel is taking a major back seat and the entry point at least will have to be re-written once I have a stable 'CBoot Specification'.
Well done to anyone who read all that
Cheers,
Adam
Project description? Initially an x86_64 kernel and associated boot loader which I am concurrently developing for 32 bit, to test the robustness of the separation of my architecture dependent and independent code. I have thought about trying an 8 bit AVR version too, but that may be pushing it a bit!
Because the kernel was taking so much time, I have started concentrating more on the boot loader (CBoot). Version 1 required GRUB, and then relocated the kernel, set up paging and a sensible GDT, switched VESA mode and set up a physical memory stack. It also has a debug console for pausing kernel loading, switching VESA mode, examining the kernel binary etc... A stack is set up, Argc and Argv are passed to the kernel which is called at its correct entry point, meaning no ASM stub. All of this is customisable based on GRUB command line parameters.
For version 2 (my current active project), I am hoping to achieve this without GRUB and make it more versatile so that others can benefit from the boot loader too (without the use of anything which is GPL'd). Version 2 will also export a unified list of hardware on various busses on the machine. Currently I only support FAT, but hope to add support for at least Ext2/3, ISO9660 and possibly in the far future, network booting. Unfortunately, all this means the kernel is taking a major back seat and the entry point at least will have to be re-written once I have a stable 'CBoot Specification'.
Well done to anyone who read all that
Cheers,
Adam
Initially my OS project was a cooperative effort. Lots of work went into infrastructure, conceptual work etc., but when we got to the point of coding, things broke apart.
Basically, I saved whatever documents and fragments of code existed, and put the project to rest, except for one sub-part - the C library, which is my "pet project" to this day.
I'm working alone. 50% because I want to avoid any licensing / legal hassles (someone sending me code he took from elsewhere, stuff like that), and 50% because it allows me to work on the project when I feel like it, without outside pressure.
Inside pressure is bad enough. Damn, it's been far too long since the last release, and I'm this close to the next one - but real life keeps me away from private coding.
Basically, I saved whatever documents and fragments of code existed, and put the project to rest, except for one sub-part - the C library, which is my "pet project" to this day.
I'm working alone. 50% because I want to avoid any licensing / legal hassles (someone sending me code he took from elsewhere, stuff like that), and 50% because it allows me to work on the project when I feel like it, without outside pressure.
Inside pressure is bad enough. Damn, it's been far too long since the last release, and I'm this close to the next one - but real life keeps me away from private coding.
Every good solution is obvious once you've found it.
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Having a family to take care of isn't that bad either, eh?
Meh, I can't remember, when I've done just some damned coding for the heck of it the last time. 'T is been 2005 or so? dunno.
not a lot of those debug sessions darker than night around anymore ...
Sadness sometimes gets a broader meaning I reckon.
stay safe
Meh, I can't remember, when I've done just some damned coding for the heck of it the last time. 'T is been 2005 or so? dunno.
not a lot of those debug sessions darker than night around anymore ...
Sadness sometimes gets a broader meaning I reckon.
stay safe
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
I hope it'll be ready once pedigree is at the libc stage, since it didn't work out for my last OS (lightOS). Don't take it serious I am just joking I really appreciate the effort you put into your public domain libc.Solar wrote:Inside pressure is bad enough. Damn, it's been far too long since the last release, and I'm this close to the next one - but real life keeps me away from private coding.
I am pretty sure that JamesM will post in this thread about pedigree and he is usually better at explaining things, so I'll just leave that to him.
Bah! You lazy German! I was going to let you have the limelight for a change.bluecode wrote:I hope it'll be ready once pedigree is at the libc stage, since it didn't work out for my last OS (lightOS). Don't take it serious I am just joking I really appreciate the effort you put into your public domain libc.Solar wrote:Inside pressure is bad enough. Damn, it's been far too long since the last release, and I'm this close to the next one - but real life keeps me away from private coding.
I am pretty sure that JamesM will post in this thread about pedigree and he is usually better at explaining things, so I'll just leave that to him.
Ah well, here goes...
Myself and bluecode are working on Pedigree - We're hoping to get an alpha release out by the end of the summer including but not limited to
* Module loading
* Network stack
* Shell
* Some* posix support
* ATA driver, and EXT2 filesystem driver
.. oh yes, and they're all going to be available on X86, X64 and PowerPC. MIPS32 maybe - it's taken a bit of a backseat to Power but I may get it up and running. Possibly. Depending on which way the wind blows
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
My kernel is based of of Linux, but not a clone. In fact, now I have started to move away a little from Linux's design. It is based off of JamesM's tutorials, and I am finishing up Beta 3 of 0.02.
-JL
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Hi,
I'm working alone, I never thought about participating in a team,I just want to keep my project as a one man vision,right now my project is paused ,I'm littel busy ...but I think I'll be back coding again in a month
or a littel more.
Good to see you again distantvoices.
I'm working alone, I never thought about participating in a team,I just want to keep my project as a one man vision,right now my project is paused ,I'm littel busy ...but I think I'll be back coding again in a month
or a littel more.
Good to see you again distantvoices.
The man who follows the crowd will usually get no further than the crowd.
The man who walks alone is likely to find himself in places
no one has ever been before.
The man who walks alone is likely to find himself in places
no one has ever been before.
-
- Member
- Posts: 566
- Joined: Tue Jun 20, 2006 9:17 am
hi,
Working alone and bunking class . . I have to join as an engineer in a firm as soon i complete my classes (yes i have agreed to it) . I do not think i will get time after that .
Regards
Sandeep Mathew
Regards
Sandeep Mathew
I'd love to work with someone else, but ASM hackers are an obstinate and independent bunch, by definition. So I'm going it alone.
My OS is just a simple desktop. Visually, something like a Win98 clone. Built around a superfast hybrid modular mini/micro-kernel, and including a custom filesystem that's twice as good as Ext or Reiser.
My OS is just a simple desktop. Visually, something like a Win98 clone. Built around a superfast hybrid modular mini/micro-kernel, and including a custom filesystem that's twice as good as Ext or Reiser.
You think your FS is that good? If it is I'd love to put support for it into pedigree. Maybe you could give me a link to your specifications document?bewing wrote:I'd love to work with someone else, but ASM hackers are an obstinate and independent bunch, by definition. So I'm going it alone.
My OS is just a simple desktop. Visually, something like a Win98 clone. Built around a superfast hybrid modular mini/micro-kernel, and including a custom filesystem that's twice as good as Ext or Reiser.
We're supporting EDI, so any driver I write should hopefully be portable to a few (at least) hobby OS's too...
I'm working alone on something like an exokernel with the intention of getting a small Lisp dialect running on top of it. Its only a hobby... at the office I don't have the chance to use assembler.
If debugging is the process of removing bugs, then programming must be the process of putting them in.
- Edsger W. Dijkstra
- Edsger W. Dijkstra