I am still working into the device manager of my OS, but I have a problem I have not resolve yet...
I want my OS load the device drivers from the disk when the user start the system, then I need a "disk driver" to load the other device drivers.
But how can I load the device drivers if there is not a disk driver loaded?
Obviously I need to have a "disk driver" encrusted into the kernel, and here is my question:
Not all the device drivers must be loadable?
Which drivers must be part of the kernel, and which must be loadable?
(I am trying the create a list of all the device drivers that must be encrusted into the kernel)
Thank you,
pepito
Basic device drivers
-
ASHLEY4
RE:Basic device drivers
You can use the bios to load a driver into memory in real mode,also the drivers that are part of the kernel is up to you,it dependeds on the design of OS.
ASHLEY4.
ASHLEY4.
-
common
RE:Basic device drivers
Well, kind of a broad question...depends totally on how you're doing your drivers...You could actually link them with the kernel during install, for example, then dump the kernel to disk...or just link them statically period. I personally intend on creating memory regions, and defining drivers within the kernel's memory area, so they'll be loaded when the kernel is...then the kernel would just initialize those regions.
Drivers required? Well, any block device required for the booting. Floppy Driver, SCSI Driver, ATA Driver, etc...along with any other required drivers to support those. For example, you may need the PCI driver if the controller is directly connected to the PCI bus.
Drivers required? Well, any block device required for the booting. Floppy Driver, SCSI Driver, ATA Driver, etc...along with any other required drivers to support those. For example, you may need the PCI driver if the controller is directly connected to the PCI bus.
-
Xenos
RE:Basic device drivers
If you have a multiboot kernel, your boot loader (GRUB...) can load a disk driver for you. In that case your kernel will need to link the driver to itself.
The other ways are linking the device driver at compile time (the easiest for the programmer, but probably not for the user) and linking at install time. It depends on which way you prefer.
The basic things you need to load drivers, i.e. read files, depend on the location of these files. If you load them from a hard disk (or floppy), you need a disk driver and a file system driver. The same is true for booting from a cd. If you boot via a network, you need a network adaptor driver and a protocol driver.
That's why I recommend boot time linking. The user tells GRUB which drivers it should load. GRUB tells your kernel what it has loaded and where you can find it. You only need to link it and use it.
The other ways are linking the device driver at compile time (the easiest for the programmer, but probably not for the user) and linking at install time. It depends on which way you prefer.
The basic things you need to load drivers, i.e. read files, depend on the location of these files. If you load them from a hard disk (or floppy), you need a disk driver and a file system driver. The same is true for booting from a cd. If you boot via a network, you need a network adaptor driver and a protocol driver.
That's why I recommend boot time linking. The user tells GRUB which drivers it should load. GRUB tells your kernel what it has loaded and where you can find it. You only need to link it and use it.
-
Anton
RE:Basic device drivers
This is a very good question, and it is more a problem of OS phylosophy, not a technical problem. The same question can be addresses to virtual memory=>how do you load the virtual memory driver, if you need to first allocate virtual memory for it? The question can also be applied to physical memory=>how do you load a physical memory driver, if you need to first allocate physical memory for it?
These questions are completely inconsistent with usual OSs phylosophy, where all operations are incapsulated in some driver. And for this reason it would be wrong to make the OS all mighty.
One of the solutions, which i see, is an OS loader. What you do is write a small "OS", which loads the real OS, and quits. Then the real OS starts working, knowing that the drivers which it need most, are loaded. And therefore, the real OS will not have any build in drivers, which is good.
Anton.
These questions are completely inconsistent with usual OSs phylosophy, where all operations are incapsulated in some driver. And for this reason it would be wrong to make the OS all mighty.
One of the solutions, which i see, is an OS loader. What you do is write a small "OS", which loads the real OS, and quits. Then the real OS starts working, knowing that the drivers which it need most, are loaded. And therefore, the real OS will not have any build in drivers, which is good.
Anton.
-
Moose
RE:Basic device drivers
Yeah but for the 'small OS' to load the 'real OS' you'd need some form of memory management inside the 'small OS' to know where free spaces of memory are to load your 'real OS', which defies the point in needing a 'small OS' in the first place.
Besides, memory management is not just a 'driver' that loads when the device starts, at least like say the one used for your sound card.
If i were to use mm in some kind of driver format, i'd place it in a grub multiboot module, and catch it after my kernel starts, then link it to become apart of the kernel.
That way, it would be changable, upgradable and so on.
Moose.
Besides, memory management is not just a 'driver' that loads when the device starts, at least like say the one used for your sound card.
If i were to use mm in some kind of driver format, i'd place it in a grub multiboot module, and catch it after my kernel starts, then link it to become apart of the kernel.
That way, it would be changable, upgradable and so on.
Moose.
-
Anton
RE:Basic device drivers
The small OS should contain everything it needs with it(liked to it). So, when the small os works, there is chaos, but then new life is born in the name of real OS. 
Whether the memory managment is a driver or not, depends on what type of kernel you have. If you have a monolithic, then defenetly it contains it. If you have a nanokernel or a microkernel, then it is a question of the OS phylosophy.
>If i were to use mm in some kind of driver format, i'd place it in a grub
>multiboot module, and catch it after my kernel starts, then link it to become
>apart of the kernel.
Then your kernel will not be portable between diferent boot devices, like CD-rom, floppy, hdd, flash memory, network, ...
Anton.
Whether the memory managment is a driver or not, depends on what type of kernel you have. If you have a monolithic, then defenetly it contains it. If you have a nanokernel or a microkernel, then it is a question of the OS phylosophy.
>If i were to use mm in some kind of driver format, i'd place it in a grub
>multiboot module, and catch it after my kernel starts, then link it to become
>apart of the kernel.
Then your kernel will not be portable between diferent boot devices, like CD-rom, floppy, hdd, flash memory, network, ...
Anton.