What the hell is needed in a kernel ?
I'm not saying you don't need one but is there a list of things
you need in a kernel ?
Steps to writing a kernel
-
Peifmaster
RE:Steps to writing a kernel
>On 2001-09-12 05:25:36, Anon wrote:
>What the hell is needed in a kernel ?
>I'm not saying you don't need one but is there a list of things
>you need in a kernel ?
The kernel provides the applications an interface to act with hardware.
if you wish to support multitasking, it has to be done in the kernel.
Also memory management is a important task of a kernel.
If you consider what an OS needs to be operational,
you will soon find out what code has to be placed
in the kernel. For examples, simple screen output,
keyboard input, interfaces to access files and so on
are necessary to do anything usefule with an OS.
>What the hell is needed in a kernel ?
>I'm not saying you don't need one but is there a list of things
>you need in a kernel ?
The kernel provides the applications an interface to act with hardware.
if you wish to support multitasking, it has to be done in the kernel.
Also memory management is a important task of a kernel.
If you consider what an OS needs to be operational,
you will soon find out what code has to be placed
in the kernel. For examples, simple screen output,
keyboard input, interfaces to access files and so on
are necessary to do anything usefule with an OS.
-
j.weeks
RE:Steps to writing a kernel
>The kernel provides the applications an interface to act with hardware.
>if you wish to support multitasking, it has to be done in the kernel.
>Also memory management is a important task of a kernel.
>If you consider what an OS needs to be operational,
>you will soon find out what code has to be placed
>in the kernel. For examples, simple screen output,
>keyboard input, interfaces to access files and so on
>are necessary to do anything usefule with an OS.
Unless you're developing a microkernel, in which case
a lot of tasks are delegated to external "drivers" or
"objects" (as is my understanding anyway).
For example, a microkernel may just include
multitasking abilities, memory management and a
few other _essential_ abilities (IPC, for sure,
or else your drivers can't talk to each other).
The other "non-core" functions, like writing to the
display and reading from the drives can be handled
externally, through drivers.
QNX does this, I believe. You can load and unload
floppy drivers as needed.
j.weeks
>if you wish to support multitasking, it has to be done in the kernel.
>Also memory management is a important task of a kernel.
>If you consider what an OS needs to be operational,
>you will soon find out what code has to be placed
>in the kernel. For examples, simple screen output,
>keyboard input, interfaces to access files and so on
>are necessary to do anything usefule with an OS.
Unless you're developing a microkernel, in which case
a lot of tasks are delegated to external "drivers" or
"objects" (as is my understanding anyway).
For example, a microkernel may just include
multitasking abilities, memory management and a
few other _essential_ abilities (IPC, for sure,
or else your drivers can't talk to each other).
The other "non-core" functions, like writing to the
display and reading from the drives can be handled
externally, through drivers.
QNX does this, I believe. You can load and unload
floppy drivers as needed.
j.weeks
-
Anon
RE:Steps to writing a kernel
This is exactly what i'm talking about.
You say something about the IPC
What the hell is that ?
What i mean by a list is that AN ACTUAL LIST of
what a kernel should have as a minimum.
osdev.org was created to help programmers to dev os.
I think complete newbies should also have a right
to know how to dev an os.
I hate it when people say "go learn more about computers"
Not that you guys did though.
You say something about the IPC
What the hell is that ?
What i mean by a list is that AN ACTUAL LIST of
what a kernel should have as a minimum.
osdev.org was created to help programmers to dev os.
I think complete newbies should also have a right
to know how to dev an os.
I hate it when people say "go learn more about computers"
Not that you guys did though.
-
Chris Giese
RE:Steps to writing a kernel
>On 2001-09-13 05:20:17, Anon wrote:
>What i mean by a list is that AN ACTUAL LIST of
>what a kernel should have as a minimum.
It doesn't take much to create a "hello, world" OS.
A more complete OS could have these things:
Device drivers that abstract the hardware, so the
tasks can process data without worrying about
whether the data comes from a floppy disk file,
hard disk file, keyboard, network connection, etc.
Filesystem code that lets you create name files
and subdirectories of any length, instead of just
treating the disks as numbered, equal-sized
blocks. Maybe a VFS layer so you can support
several different filesystems.
Syscalls to make kernel services available to the
tasks:
functions to load and run tasks (fork, exec, spawn)
functions to let tasks allocate memory (sbrk, mmap)
functions to read/write files and read directories
(open, lseek, read, write, readdir, close, stat)
Maybe functions that let tasks communicate with
each other (IPC). This is less important in a
monolithic kernel.
>What i mean by a list is that AN ACTUAL LIST of
>what a kernel should have as a minimum.
It doesn't take much to create a "hello, world" OS.
A more complete OS could have these things:
Device drivers that abstract the hardware, so the
tasks can process data without worrying about
whether the data comes from a floppy disk file,
hard disk file, keyboard, network connection, etc.
Filesystem code that lets you create name files
and subdirectories of any length, instead of just
treating the disks as numbered, equal-sized
blocks. Maybe a VFS layer so you can support
several different filesystems.
Syscalls to make kernel services available to the
tasks:
functions to load and run tasks (fork, exec, spawn)
functions to let tasks allocate memory (sbrk, mmap)
functions to read/write files and read directories
(open, lseek, read, write, readdir, close, stat)
Maybe functions that let tasks communicate with
each other (IPC). This is less important in a
monolithic kernel.
-
j.weeks
RE:Steps to writing a kernel
>On 2001-09-13 05:20:17, Anon wrote:
>This is exactly what i'm talking about.
>You say something about the IPC
Inter-process communication. It's a protocol (that
you will device) to allow your programs and threads
to talk to each other (since they'll no doubt be
in different memory spaces, this can sometimes be
difficult)
>What i mean by a list is that AN ACTUAL LIST of
>what a kernel should have as a minimum.
Well, it's almost impossible to say, really, because
you conceivable _could_ have a kernel that did Nothing!
The applications themselves would then have to implement
memory management and all that.
I can't give you an exhaustive list, but I can
perhaps start, and others can add on as they see fit.
memory management, for sure
virtual paging, if you decide to implement it
multitasking
IPC
your load/run drivers/executables code
low level stuff like dma, the rtc, pic, etc.
I'm sure there's other stuff, but it's different
for each kernel, really. Some people decide
not to include certain features, or to add
others, or to put them in drivers instead of the
kernel.
Your best bet is to make a small kernel that does
nothing, and load and run it. If it works, slowly
add on to it. Add keyboard support, if you want,
or video support... whatever you wanna put into it,
and then test it again, until it's to the point
where you feel it's done.
>osdev.org was created to help programmers to dev os.
>I think complete newbies should also have a right
>to know how to dev an os.
newbies to os development, or newbies to programming
in general. The former, yes, for sure. But the
latter, I'm no so sure. No one new to programming
should try to develop an operating system. It's not a
task for a newbie, and they're just gonna end up
getting really frustrated, or they'll just end up
copying someone else's code and cut and pasting
it into their own, and that's no good - you're not
learning anything, and your ripping off someone's
code.
>I hate it when people say "go learn more about computers"
>Not that you guys did though.
Well, it is the best way to learn. If you're developing
and operating system, you've gotta know _a lot_
about the internal workings of a computer. Particularly
the PIC and all that... it's not something you can
just look at someone else's code and say, "Oh, yeah,
that's how that works!"
j.weeks
>This is exactly what i'm talking about.
>You say something about the IPC
Inter-process communication. It's a protocol (that
you will device) to allow your programs and threads
to talk to each other (since they'll no doubt be
in different memory spaces, this can sometimes be
difficult)
>What i mean by a list is that AN ACTUAL LIST of
>what a kernel should have as a minimum.
Well, it's almost impossible to say, really, because
you conceivable _could_ have a kernel that did Nothing!
The applications themselves would then have to implement
memory management and all that.
I can't give you an exhaustive list, but I can
perhaps start, and others can add on as they see fit.
memory management, for sure
virtual paging, if you decide to implement it
multitasking
IPC
your load/run drivers/executables code
low level stuff like dma, the rtc, pic, etc.
I'm sure there's other stuff, but it's different
for each kernel, really. Some people decide
not to include certain features, or to add
others, or to put them in drivers instead of the
kernel.
Your best bet is to make a small kernel that does
nothing, and load and run it. If it works, slowly
add on to it. Add keyboard support, if you want,
or video support... whatever you wanna put into it,
and then test it again, until it's to the point
where you feel it's done.
>osdev.org was created to help programmers to dev os.
>I think complete newbies should also have a right
>to know how to dev an os.
newbies to os development, or newbies to programming
in general. The former, yes, for sure. But the
latter, I'm no so sure. No one new to programming
should try to develop an operating system. It's not a
task for a newbie, and they're just gonna end up
getting really frustrated, or they'll just end up
copying someone else's code and cut and pasting
it into their own, and that's no good - you're not
learning anything, and your ripping off someone's
code.
>I hate it when people say "go learn more about computers"
>Not that you guys did though.
Well, it is the best way to learn. If you're developing
and operating system, you've gotta know _a lot_
about the internal workings of a computer. Particularly
the PIC and all that... it's not something you can
just look at someone else's code and say, "Oh, yeah,
that's how that works!"
j.weeks