OSDev.org

Yo:

In reality, the only thing that is preventatively obscure in the writing of a desktop kernel today is driver writing. Firmware interfaces, ACPI, CPU architectures, chipset specifics, and all of those other details are far too well documented for there to be a need for any type of altruistic community standardization effort. Encryption/compression algorithms are freely implemented in libraries. Programs for every purpose are freely available. You need only write your kernel.

-----------------------------------------------------------
-------------------------------------------------------------
----------------------------------------------------------
--------------------------------------------------------------
------------------------------------------------------------
-------------------------------------------------------------
Instead of idealizing solutions for a problematic world which does not exist, and spamming posts about those imaginary solutions to your imaginary problems, maybe you should actually get down to writing a kernel.

--Peace out,
gravaera.

Hi,

~ wrote:

Griwes wrote:There are two things wrong in this part. First one is: only in utopia you can have single variant of everything, and, as you probably know, utopias can not exist. Plus it limits user's choice, which is a Bad Thing. Second one is quite well summarized by this well known XKCD:

I don't see how having for example a single kind of network card that has all of the capabilities of the existing ones would limit the user's choice. It would actually increase them if we assume that the same driver (a single driver) could be used for decades, and it would be fully known how to program (which means it would be from possible to easy to do, unlike the current situation).

Many different/incompatible devices for the same purpose is annoying; but there's another side to the story. If you tried to get several competing companies to form a committee to design a single specification for something, then the resulting specification will be a hideous mess, and that specification will either prevent future hardware improvements or end up buried under non-standard vendor specific extensions.

I still think that (as OS developers) our main goals should be:

• to design and provide APIs that are capable of supporting the features of modern hardware (including future-proofing - e.g. things like 3D monitors in case they become popular)
• to provide some generic code for devices if/where possible (that may only implement a subset of the device's API's functionality)
• to provide "proof of concept" applications/utilities that use the APIs
• to provide the foundation to make all this possible (boot code, kernel, TCP/IP, GUI, VFS, etc)
• to provide public documentation of APIs, tutorials (e.g. "how to write a network card driver for BCOS"), and other information so that it's possible for other people to write applications and device drivers (without digging through your source code in a painful and slow way and/or guessing and/or asking you hundreds of questions)
• to provide anything else that can make writing a device driver easier; possibly including example code or a "dummy driver" they can add device specific code too (without doing the boilerplate stuff), or maybe a utility that tests the driver (so they don't need to worry about writing their own end-to-end tests)
• make all of the above so awesome that people (and companies) want to write applications and device drivers for your OS
• if/when people do spend their time writing applications and device drivers for your OS; don't kick them in the face by changing your APIs and breaking their work (after people have written stuff for your OS, backward compatibility is extremely important; which means that while the OS is being designed it needs to be designed well to ensure backward compatibility).

I personally guarantee that if you do all of these things, your OS will succeed (people will start use it for something, and will write software/drivers for it, and it will grow from there). Of course I'm not silly - if your OS doesn't succeed then I'm just going to tell you it wasn't awesome enough.


Cheers,

Brendan

Hi,

rdos wrote:For the moment there is a perfectly useful solution to the UEFI problem: Don't bother with UEFI and use legacy booting and VBE even when computer has an UEFI BIOS. Works on all UEFI BIOSes tested this far.

When you have to fight an angry bear, just bite his testicles off and he will be your friend. It's worked on every angry bear I've fought so far.


Cheers,

Brendan

Brendan wrote:

rdos wrote:For the moment there is a perfectly useful solution to the UEFI problem: Don't bother with UEFI and use legacy booting and VBE even when computer has an UEFI BIOS. Works on all UEFI BIOSes tested this far.

When you have to fight an angry bear, just bite his testicles off and he will be your friend. It's worked on every angry bear I've fought so far.

Why? Until I have a physical machine with UEFI that doesn't support legacy booting I see no reason why I should do anything for UEFI. UEFI won't give me any advantages, just a number of problems, so why bother? Hopefully, UEFI is just a fad that eventually will be replaced by something better.

rdos wrote:Until I have a physical machine with UEFI that doesn't support legacy booting

Someone send the sad person a secondhand mac mini. With a bit of luck he'll shut up for a few years until all his code is actually fixed properly

Hi,

rdos wrote:

Brendan wrote:

rdos wrote:For the moment there is a perfectly useful solution to the UEFI problem: Don't bother with UEFI and use legacy booting and VBE even when computer has an UEFI BIOS. Works on all UEFI BIOSes tested this far.

When you have to fight an angry bear, just bite his testicles off and he will be your friend. It's worked on every angry bear I've fought so far.

Why? Until I have a physical machine with UEFI that doesn't support legacy booting I see no reason why I should do anything for UEFI. UEFI won't give me any advantages, just a number of problems, so why bother? Hopefully, UEFI is just a fad that eventually will be replaced by something better.

The fact that it "works on all UEFI BIOSes tested this far" only means that you haven't tested enough.

"UEFI only" 80x86 systems already exist (e.g. Levono ThinkPad Tablet 2, most 80x86 Apple machines, etc). This will become more common as time passes (and I still think it'll become extremely common for desktop/server systems once consumers stop caring about Windows XP).

It makes no difference if you like it or not, this is the way the industry is heading. Burying your head in the sand and ignoring the problem, or hoping that UEFI will just vanish for no reason "soon" (even though all manufacturers have adopted it and despite the fact that it took about 35 years for BIOS to do the same) is just plain retarded.

The first step towards fixing a problem is admitting you have a problem. Start by recognising that (in hindsight) the assumption that an OS will always be able to switch video modes after boot is a design flaw.

Also note that UEFI does fix some problems. For example, using UEFI you can set video modes for multiple monitors during boot, so that people with multiple monitors and/or multiple video cards actually end up with better support than they would have with BIOS/VBE.


Cheers,

Brendan

Brendan wrote: The fact that it "works on all UEFI BIOSes tested this far" only means that you haven't tested enough.

"UEFI only" 80x86 systems already exist (e.g. Levono ThinkPad Tablet 2, most 80x86 Apple machines, etc). This will become more common as time passes (and I still think it'll become extremely common for desktop/server systems once consumers stop caring about Windows XP).

I'm not likely to buy a Mac/Apple PC anytime soon, so if it is only those that no longer support legacy boot, I don't see the problem. Those machines never supported BIOS, so it's no wonder if they only support UEFI.

Brendan wrote: The first step towards fixing a problem is admitting you have a problem. Start by recognising that (in hindsight) the assumption that an OS will always be able to switch video modes after boot is a design flaw.

I'd rather see it as a feature. A feature that doesn't need to be supported on particular hardware. However, when I buy a new machine, I look at the hardware and if a particular machine appear to have some essential hardware I don't support, I'm less likely to want to buy it. At the very minimum, I would not buy a machine where every hardware piece doesn't already have an existing driver for RDOS, or at the minimum have hardware with publicly available specifications. Having a UEFI BIOS that I know doesn't support legacy booting will make me not buy the machine, at least if there are alternatives.

Brendan wrote: Also note that UEFI does fix some problems. For example, using UEFI you can set video modes for multiple monitors during boot, so that people with multiple monitors and/or multiple video cards actually end up with better support than they would have with BIOS/VBE.

Not relevant for me. I don't support multiple monitors at the moment, and I have no plans to add such support anytime soon.

Combuster wrote:

rdos wrote:Until I have a physical machine with UEFI that doesn't support legacy booting

Someone send the sad person a secondhand mac mini. With a bit of luck he'll shut up for a few years until all his code is actually fixed properly

It won't take a few years to fix UEFI and fixed video mode support. More like a few weeks. But as I have better things to do, I won't do it until I must.

rdos wrote:Why? Until I have a physical machine with UEFI

This is the number one issue with your mindset.

Someone out there may have a UEFI-only machine and the desire to run RDOS on it. And in saying that you don't want to support UEFI at all makes them sad and makes you look incredibly silly.

Blacklight wrote:

rdos wrote:Why? Until I have a physical machine with UEFI

This is the number one issue with your mindset.

Someone out there may have a UEFI-only machine and the desire to run RDOS on it. And in saying that you don't want to support UEFI at all makes them sad and makes you look incredibly silly.

That's not likely to happen, as I don't work that way. I keep BSPs for different machines that are known to work. I have BSPs for all the configurations that are running on my company, for my development machines, for possible future hardware we might use, and also for all machines I owe myself. If somebody wants to run RDOS on something, they should first look at the supported hardware list, and then which software components they need. Then they can evaluate if their project is reasonable, and how much it might cost in terms of investment in hardware and possibly writing new drivers for things that aren't supported right now. That's the way everybody needs to reason when selecting some OS other than Windows or *nix clone.

The way many of you seem to reason is that every fancy feature should be supported and work, and all possible hardware and software interfaces should be available. That's a pretty high goal which means you never will finish your projects.

Every logical feature should be supported and should work on a variety of platforms for a variety of end-users. I do not intend on writing drivers for every device I come across, but I do intend on writing drivers for the ones that logically should have working drivers for.

UEFI is displacing the legacy BIOS. Not supporting it is illogical.

rdos wrote:If somebody wants to run RDOS on something, they should first look at the supported hardware list, and then which software components they need. Then they can evaluate if their project is reasonable, and how much it might cost in terms of investment in hardware and possibly writing new drivers for things that aren't supported right now. That's the way everybody needs to reason when selecting some OS other than Windows or *nix clone.

Everyone should build a new computer just so they can run a different OS? I'm sorry, but that's just plain stupid.

No wonder we've never seen your OS in action. It can't run on anything but a strict set of hardware that only you seem to have and therefore isn't worth using.

Blacklight wrote:Every logical feature should be supported and should work on a variety of platforms for a variety of end-users. I do not intend on writing drivers for every device I come across, but I do intend on writing drivers for the ones that logically should have working drivers for.

Of course.

Blacklight wrote:UEFI is displacing the legacy BIOS. Not supporting it is illogical.

I only claimed that supporting UEFI right now makes no sense. It is possible that it makes sense in 5 or 10 years time, but right now I have no plans to support it.

Generally, it makes the most sense to develop things for common hardware/interfaces that are in extensive use. If you write drivers for things that are not in extensive use, it is quite possible that you work on things that never will come into common use. Exceptions are if you really need some feature, and then develop drivers in the context of the project that needs the feature.

Blacklight wrote:No wonder we've never seen your OS in action. It can't run on anything but a strict set of hardware that only you seem to have and therefore isn't worth using.

You already might have, and the possibility you will in the future increases.

The list of supported hardware makes it run on most computers. Typically, it is the network driver that might be problematic as there exist many of these, however RTL8139 and RTL8169 (and compatible types) are quite common today.

rdos wrote:

Brendan wrote: The fact that it "works on all UEFI BIOSes tested this far" only means that you haven't tested enough.

"UEFI only" 80x86 systems already exist (e.g. Levono ThinkPad Tablet 2, most 80x86 Apple machines, etc). This will become more common as time passes (and I still think it'll become extremely common for desktop/server systems once consumers stop caring about Windows XP).

I'm not likely to buy a Mac/Apple PC anytime soon, so if it is only those that no longer support legacy boot, I don't see the problem. Those machines never supported BIOS, so it's no wonder if they only support UEFI.

What about my device, a 2012 HP Pavilion? It technically does support legacy bios, but it's a pain and glitchy.
What about most current Dell and Lenovo computers? Or 90% of computers (especially tablets) which ship with Windows 8?

Brendan wrote: The first step towards fixing a problem is admitting you have a problem. Start by recognising that (in hindsight) the assumption that an OS will always be able to switch video modes after boot is a design flaw.

I'd rather see it as a feature. A feature that doesn't need to be supported on particular hardware. However, when I buy a new machine, I look at the hardware and if a particular machine appear to have some essential hardware I don't support, I'm less likely to want to buy it. At the very minimum, I would not buy a machine where every hardware piece doesn't already have an existing driver for RDOS, or at the minimum have hardware with publicly available specifications. Having a UEFI BIOS that I know doesn't support legacy booting will make me not buy the machine, at least if there are alternatives.

So, in other words, you're saying you don't want growth for your OS?

Brendan wrote: Also note that UEFI does fix some problems. For example, using UEFI you can set video modes for multiple monitors during boot, so that people with multiple monitors and/or multiple video cards actually end up with better support than they would have with BIOS/VBE.

Not relevant for me. I don't support multiple monitors at the moment, and I have no plans to add such support anytime soon.

Look at my last comment...

If an OS is meant to work on special hardware, it is fine per se. There are many reasons why limiting the scope can make things better. For example, writing an OS in assembly makes it highly architecture dependent but it is possible to make it extremely efficient that way. Without any compromises that result in making a portable system. It is possible to take out all the hardware potential if making the code for the specific hardware. However, the portable system written in a high-level language usually ends up being more efficient, as a side effect...

When it comes to this issue we are talking about here: it does not make sense to limit the hardware scope without gaining any advantage out of it. Even just making a UEFI-compatible OS and then inactivating this UEFI-compatibility results in a better OS than the BIOS-only approach. It should not make the OS any better to keep it BIOS-only.

As a matter fact, I do not understand the resistance to change in general. UEFI is not perfect but it is not that bad it should be avoided to the last. If we tried to be objective, UEFI would be more elegant than BIOS with its 30-year-old quirks.

Antti wrote: When it comes to this issue we are talking about here: it does not make sense to limit the hardware scope without gaining any advantage out of it. Even just making a UEFI-compatible OS and then inactivating this UEFI-compatibility results in a better OS than the BIOS-only approach. It should not make the OS any better to keep it BIOS-only.

It has to do with priorities. If I had infinite time available, I'd support all hardware, software and boot standard there is. But that is not the case, so I prioritize things I want to do. Among the things that have higher priority than supporting UEFI is to finish the long mode port, rewrite the VFS and FAT implementation in C, and add ext, cdfs and USB disc support.