)
Anything wrong with that?Building all device drivers into the kernel will (eventually) result in a huge kernel where most of it is unused. To get around this often the kernel is distributed as source code that the user is expected to compile for their computer. In this way code can be added or removed using conditional code, resulting in a kernel that is customized for the specific computer.
While this method can give the best possible performance it also restricts the potential number of users and uses of the OS , as a lot of computer users aren't programmers and don't know how to compile, etc. It can also make the OS's installation process messy and over-complicated.
OrgName: Asia Pacific Network Information Centre
OrgID: APNIC
Address: PO Box 2131
City: Milton
StateProv: QLD
PostalCode: 4064
Country: AU
ReferralServer: whois://whois.apnic.net
Should be obvious.bubach wrote: Building all device drivers into the kernel will (eventually) result in a huge kernel where most of it is unused.
The Linux kernel is distributed as source because 1) it's GPL, and 2) lacking any defined ABI so you have to re-compile your driver modules with every new kernel version. That's a completey different can of fish (which stinks IMNSHO), and hasn't much to do with the kernel design. Windows is also mostly monolithic, but has a fixed ABI so it needn't be shipped as source.To get around this often the kernel is distributed as source code that the user is expected to compile for their computer.
You can do the same without shipping as source and requiring recompiles.In this way code can be added or removed using conditional code, resulting in a kernel that is customized for the specific computer.
While the result of a self-compile kernel are described correctly, it doesn't have anything to do with the kernel being monolithic in design.While this method can give the best possible performance it also restricts the potential number of users and uses of the OS , as a lot of computer users aren't programmers and don't know how to compile, etc. It can also make the OS's installation process messy and over-complicated.
Do you honestly believe this (for any type of kernel)? Think about removing all the "if(computer_supports_X) then <something> else <something else>" code. Consider PAE, global pages, FPU native exceptions, INVLPG, FXSAVE, etc, and processor specific optimizations (like "Is a series of ADD instructions faster than LEA?"), unrolling loops to the size of the L1/instruction trace cache, etc. This is just the CPU, there's the hardware side of things too - is it an 80486 without PCI, is it a newer computer without ISA, is there a USB bus, are there IO APICs, SMP, NUMA, etc. I guess it is possible - you'd just need to distribute thousands of pre-compiled kernels to do it.You can do the same without shipping as source and requiring recompiles.In this way code can be added or removed using conditional code, resulting in a kernel that is customized for the specific computer.
That's an understandable comment - I should have elaborated further.While the result of a self-compile kernel are described correctly, it doesn't have anything to do with the kernel being monolithic in design.While this method can give the best possible performance it also restricts the potential number of users and uses of the OS, as a lot of computer users aren't programmers and don't know how to compile, etc. It can also make the OS's installation process messy and over-complicated.
There was no attempt to harm the wiki's content or to advertise (which is unusual for me as I have a tendancy to write "my OS does X like Y"ineo wrote: Unfortunately we are all having more and more problems with wikis...
This kind of mistakes are not so bad when pages are regularly checked. But I hate this new wiki spamming.
Maybe it will be a good idea to have user registration. It shouldn't stop people from contributing, and it will allow minimal security checks. Furthermore you'd be able to explain to somebody its mistakes.
). Nor have I (now or ever) attempted to hide my actions. I even put my name in the "Sign in" box before I clicked "edit" but the wiki ignored it.
I agree. Next time, I think it would be wise to just move disputed content to its own new page rather than simply delete it. I think it's useful to discuss source vs. binary distribution of OSes, although I agree that this is not a micro vs. monolithic issue.Brendan wrote: I agree that "Building all device drivers into the kernel will (eventually) result in a huge kernel where most of it is unused." should be obvious, and definately is for most of the regulars here, but most of the regulars here don't have any need for the wiki pages on kernel types. For the people that do need these wiki pages I don't think the statement is obvious.
I was pretty sure that all Win9x drivers ran in the kernel's address space, except maybe real-mode drivers that run in V8086 mode. Do you have a source for this...?Perhaps it's something to do with which part of the address space device drivers run? For windows 95/98 device drivers run in their own part of the address space, not within the kernel's part of the address space and not within process space either.
Nope. The HAL is just a library of functions that do machine-specific things. It encapsulates details like whether the kernel is MP or UP, whether it uses the PIC or APIC, etc. Kernel-mode drivers run at CPL=0, in the address space of the kernel. NT is not a microkernel IMO.For windows XP and NT there's a hardware abstraction layer and (AFAIK) device drivers run at CPL=3.
My knowledge of Microsoft OS's is fairly limited. I just assumed and didn't bother checking as exact details weren't too relevant to the context it was used - I was trying to show the difficulty that is involved with a definitive definition of "monolithic kernel". For example "An OS kernel that is entirely self contained and does not call in additional drivers or modules as needed." (from http://www.techweb.com/encyclopedia/def ... thickernel). This implies that Linux isn't a monolithic kernel. I don't agree with this definition (I'd call it a "pure monolithic kernel" rather than just a "monolithic kernel").Colonel Kernel wrote:I was pretty sure that all Win9x drivers ran in the kernel's address space, except maybe real-mode drivers that run in V8086 mode. Do you have a source for this...?
Yep, Win9x was quite a monstrosity. I think the "system DLLs" refer to user-mode things like the Win32 API (kernel, GDI, and user).Brendan wrote:I did find a microsoft page (http://msdn.microsoft.com/library/defau ... _space.asp) that says "system DLL's" are between 0x80000000 and 0xBFFFFFFF, and "low-level system code" goes from 0xC0000000 to 0xFFFFFFFF. It doesn't say if part of either of these larger areas is used specifically for device drivers or not. This page also claims that both areas are writeable by any process and gives a warning about catastrophic consequences? - I find that remarkably crappy design if it's correct.
Not that unusual... NT also has user-mode drivers for similar things, but AFAIK they need kernel-mode counterparts that actually do the I/O.Stangely enough I also found a page claiming that "In addition to VxDs, Windows 3.x/95 supports non-privileged (ring-3) Communication and Printer drivers. These are typically given .DRV file extensions." (from http://www.cs.uu.nl/wais/html/na-dir/wi ... g/vxd.html).
I've prepared a draft version of it and attached it to this message. I was thinking of perhaps adding it to the main page under "Basic Information", between "introduction" and "Beginner Mistakes".Solar wrote:Brendan, your effort to get rid of the brain surgery / knife questions (very nice metaphor there!) is appreciated. I'd recommend one of the pages in the "Basic Information" chapter for that, probably "Beginner Mistakes".
Ahhh - my mistake
.It's called caffeine, and trust me it doesn't work as well as it could. I woke early on Friday morning, went to work, came home, read boards, played games and messed with my OS. At around 4 in the morning (after being awake for some 23 hours) I saw the first 2 messages here and preceeded to over-react somewhat :-\. Anyway I ended up going to sleep at 2 on Saturday afternoon, slept for 12 hours and woke at 4 this morning, thereby completing my 48 hour day...Solar wrote:Again, sorry if I did offend you. (Where's that machine that turns days into 48-hour length?) :-\
I think by this definition, recent versions of the Linux kernel would qualify as macrokernels (modular) rather than monolithic (big code soup w/ everything compiled in).A microkernel, on the other hand, is the name given to the core portion of a modern, modular operating system. Microkernel operating systems are based on two fundamental principles. The most basic principle is one of modularity, encapsulation, and data hiding. In this aspect of the design, there is one and only one portion of the operating system that has system-wide responsibility for a particular function. All other parts of the operating system (as well as applications, naturally) access that function through a well-defined interface. There is no duplication of function and no "back doors" to critical data structures; all access to system data structures is through software interfaces. This approach makes it possible to upgrade or replace entire modules within the system without disturbing the remainder. A secondary principal of the microkernel design, related to the first but focused more on the implementation strategy, is that large portions of the operating system which traditionally run entirely in the kernel or privileged mode of the microprocessor can now be executed in user or application mode, with only the microkernel itself, along with a relatively small amount of hardware device-specific code, executing in kernel mode.
Operating systems that follow both of these principles are often called pure microkernel systems. Operating systems that follow the first principle only?strict modularity and strong encapsulation?but not the second, are sometimes called modifiedmicrokernel or macrokernel operating systems.
