Combuster wrote:There's a page on the old wiki nobody cared to port yet: ... I think it does just that
The point was that I am going to agree with jhawthorn on this specific point -- having to navigate all the way into one particular article to find any old abbreviation whatsoever is non-intuitive, and where would you stick the article anyway (which category)?
Combuster wrote:IMO, its everything put into copper, silicon, and aluminum casings.
I'd say that's too broad. That just means "everything except theory". If that's what it's supposed to be, then label it that way.
Combuster wrote:so basing the category tree on the intel architecture alone is IMO not good
I was saying that based on the fact that the "Hardware" category is
already tilting hard in that direction. I disagree that "architecture" and CPU mean the same thing. A Mac is an architecture, no matter what CPU it uses, and the same for a PC. And that is the big problem I see with your organization for "Hardware".
Someone coming to this wiki is only interested in
ONE architecture. The one they are coding for. To use your "Hardware" tree, they would need to look at PC architecture under each separate heading of Common Devices, Communication, Input Devices, Peripheral Buses, Sound, Storage, Video, and "Architecture". This is not intuitive or efficient. If someone is programming a PC, they should click a category that says "PC architecture", and all of those headings whould be subcategories under PC Architecture, so that they are grouped rationally. And there would be a separate main Architecture category for Macs, because the hardware setup for Macs is totally different, and should not be mixed with the hardware specs for PC architectures.
Combuster wrote:In contrast to hardware, the software is what we are developing. I.e. the contents of that is up to us osdevers.
But pretty much everyone needs a bootloader, don't they? We are boxed in, to some degree, by the architecture we are programming for -- its boot sequence, memory mapping layout, etc. People visiting the wiki need to be informed what those software limitations are. We also need to be informed how to interface with pre-existing OSes. These are all software issues.
Combuster wrote:If you would indeed to introduce such a category it might introduce a feeling of being forced into some doctrine.
Perhaps, but I was trying to make the point that "Booting" is not a hardware specific task. It is a software specific task having to do with your kernel. The same with "Interrupts" to a large degree. GDTs & Interrupt tables. "How to Enter & Exit a particular CPU mode". Specific filesystem formats. These are all abstractions above hardware level concepts. So putting them in a category named "Hardware" is non-intuitive.
Combuster wrote:- It looks like your architecture category is doubled. (other architectures vs cpu types)
As I said, a Mac is not a CPU type, and a K2-266 chip is not an architecture. An architecture is a box. A CPU is a chip. If you want to put the word "Chip" after all my CPU types, that might clarify it.
Combuster wrote:- I think I/O should be separated into input devices (mouse, KB) and communication devices (serial port, NICs)
I just don't see a good reason to make a separate category for only mouse and KB, which are just unidirectional communication devices. And "communication devices" would seem to include modems, and muxes, and routers. I think the category name would be a little unclear.
Combuster wrote:- USB is a bus, i think it should be categorized as such
OK.
Combuster wrote:- Why make the distinction between various x86 compatibles - they all support the basic instruction set, and this listing looks confusing
Because one reason to be looking at this wiki is to be looking for special issues regarding the particular CPU that you are programming for. Chip bugs are specific to one manufacturer, and chipline. Optimization issues are also specific to manufacturers. And the main point is that it is the
differences from the basic instruction set that are vital to know about. Lack of CPUID function. Lack of MTRRs. Different MSR set.
Combuster wrote:Kernels and Drivers may be software, but they are directly dealing with one or more pieces of hardware.
I disagree about kernels. Kernels are one level of abstraction away from dealing with hardware. They are software.
Combuster wrote:As would the boot sequences for each architecture (which are btw missing in your tree).
My tree was assuming that we would be aiming primarily at only PC architecture. Boot sequence in mine would be under Booting, in Software. And my tree was intended as an example, not to be complete.