Ideal Computer Machines

[rdos]

Now I am really confused.

You are aware that UDI has been benchmarked? And that UDI drivers performed on par, sometimes even better, than native drivers?

That would imply that there are some UDI drivers available. If there are only UDI-drivers for older, simple, hardware, why would I bother with UDI? If there are no new, hot, drivers that I don't have (like wireless NICs, AHCI or USB discs), why should I write UDI versions instead of native versions? It would probably take less time to port the Linux versions to native RDOS version than to port them to UDI, and the result would be better.

[rdos]

I think you completely misunderstood the purpose of the reference implementation. It is an example for how UDI could be implemented, not a framework to be ported to your OS. Your OS has quite specific requirements and conditions, so a "good" UDI implementation for RDOS might look significantly different from what udiref provides.

Possibly, but the ACPICA comes with supporting functions for different OSes in the reference implementation. It seems to me that the UDI specification is not exact enough if it is not possible to write a reference implementation with a working framework for some OSes.

Additionally, the ACPICA reference implementation does have exactly the same issues as UDI, but decides to provide a precise function-set for OS implementators. For instance, ACPICA have functions for memory, IO, mapping physical memory, PCI, spinlocks, semaphores and delayed execution of commands. Why couldn't such an interface be added to UDI?

[Love4Boobies]

If there are only UDI-drivers for older, simple, hardware, why would I bother with UDI? If there are no new, hot, drivers that I don't have (like wireless NICs, AHCI or USB discs), why should I write UDI versions instead of native versions? It would probably take less time to port the Linux versions to native RDOS version than to port them to UDI, and the result would be better.

The result wouldn't be better, it would just be more drivers that don't perform as well

Either way, I already answered that question: You should decide what you want---no one here is trying to convince you to go UDI, we just wanted to clear a few erronous things up, that's all. As for the benefit, it's in my previous answer. You might also want to refer to Deven Cozine's editorial.

Now I am really confused.

Possibly, but the ACPICA comes with supporting functions for different OSes in the reference implementation. It seems to me that the UDI specification is not exact enough if it is not possible to write a reference implementation with a working framework for some OSes.

Well, udiref was supposed to be a way to verify whether the specification was correct, at first. Then it started growing into something similar to what ACPICA is for ACPI today. Unfortunately, the FSF had their way and UDI was more or less forgotten. It could still use some improvements but it's usable.

Additionally, the ACPICA reference implementation does have exactly the same issues as UDI, but decides to provide a precise function-set for OS implementators. For instance, ACPICA have functions for memory, IO, mapping physical memory, PCI, spinlocks, semaphores and delayed execution of commands. Why couldn't such an interface be added to UDI?

ACPICA has those things, yes. ACPI, however, does not. UDI is similar to ACPI, not ACPICA. What UDI does is to describe how drivers should be written in a portable way and still achieve very good performance. What it does not to is to describe how it should be implemented in the OS---it's similar to C in that regard: it describes how to write programs and what their behavior should be but NOT their ABI.

[rdos]

Well, udiref was supposed to be a way to verify whether the specification was correct, at first. Then it started growing into something similar to what ACPICA is for ACPI today. Unfortunately, the FSF had their way and UDI was more or less forgotten. It could still use some improvements but it's usable.

I don't understand the reasoning of FSF. UDI is not a binary format, and does not even have a reference implementation in source-format for many OSes, so how could UDI drivers be shipped in binary form for many OSes?

More likely, the Linux project don't want competition from other OSes, and thus just ignores UDI. Most major OSes have also ignored ACPICA, but still provide native ACPI support. However, for UDI, it seems like no major OS really supports it, and thus it is a dead project since nobody write drivers for UDI.

[Love4Boobies]

You don't understand it because it makes no sense, that's why They were afraid people would start running non-GPL drivers on Linux (this already happens, btw), as UDI doesn't care how people wish to license their drivers; udiref itself is written against a BSD-style license.

[rdos]

You don't understand it because it makes no sense, that's why They were afraid people would start running non-GPL drivers on Linux (this already happens, btw), as UDI doesn't care how people wish to license their drivers; udiref itself is written against a BSD-style license.

IMO, Linux today could be compared to any propietary OS. The only difference is that it is owned by the FSF, and not by a company charging customers. In all other respects, Linux is like Windows.

If FSF wanted to boost free drivers, they could have given input to the UDI project in order to fit the UDI to the internals of Linux in such a way that UDI drivers worked better on Linux than on Windows. They did not do this because they wanted to have their own non-shareble drivers just like any other closed-source OS.

[Solar]

@rdos:

You nailed it.

In a very real sense, Linux (the kernel, anyway) is not about "sharing" at all. The combination of "all drivers must be GPL" (i.e., "contagious" to your kernel should you copy them) and "we reserve the right to refactor the kernel/driver interface on a whim" (i.e., any cleanroom reimplementation would be aiming at a moving target) is no different than Microsoft's defensive tactics.

[Love4Boobies]

IMO, Linux today could be compared to any propietary OS. The only difference is that it is owned by the FSF, and not by a company charging customers. In all other respects, Linux is like Windows.

That's not really true. The Linux kernel is owned by the developers and companies that contributed to it. As for the GNU utilities, they are owned by the FSF (i.e., not by the actual developers), AFAIK. So if you're talking about GNU-based Linux distributions (a.k.a. GNU/Linux), then the copyright is further split.

If FSF wanted to boost free drivers, they could have given input to the UDI project in order to fit the UDI to the internals of Linux in such a way that UDI drivers worked better on Linux than on Windows. They did not do this because they wanted to have their own non-shareble drivers just like any other closed-source OS.

UDI is specifically developed to be OS-independent and to perform well in every scenario. Sounds like you're trying to make its design worse---UDI was never supposed to be a Linux driver interface.

I do agree with the point you were trying to make, though.

[DavidCooper]

It may be that UDI could become a bolt-on package to work as a modern (and much more advanced) BIOS replacement on machines which only boot using EFI, and the death of the BIOS might in itself trigger manufacturers into backing UDI once they no longer have to spend time on all the old legacy stuff.

I'm not sure what you think the connection is between firmware and driver interfaces. They are two independent things.

I wasn't suggesting it would be part of the firmware - when I use the term BIOS I'm thinking purely in terms of it as a basic input/output system. Here's the idea: ignoring all the initial set-up stuff, the BIOS is really an auxiliary operating system which provides lots of services to the main OS, and in the old days where the main OS stayed in real mode it could continue to rely on the BIOS for much of its functionality. Clearly it isn't as much use once in protected or long mode, but something equivalent could be designed which would sit in RAM and be loaded before the main OS. Imagine a program which boots from a USB flash drive to check out the hardware on the machine it's been booted on: it loads in the appropriate drivers for all the hardware it finds and builds them into a BIOS-style block of functionality, and then it triggers the loading of the main OS (probably from a different partition). The Main OS knows that the UDI-BIOS (for want of a better name) will be sitting there in RAM and that an IDT has been set up already - this will make available to the OS VESA-style capabilities and USB loading and saving to all manner of devices, plus a whole lot more capability relating to mice, sound cards and the like. The whole thing would work in 32-bit mode.

With such an auxiliary OS available (this would be the community OS project), any hobby OS could be designed to run alongside it, and most of the design of that main OS would be free to take its own direction without being limited by the UDI-BIOS. The main OS could then bypass parts of the UDI-BIOS and modify the IDT entries as its own capability grows, but another trick would be that it could rewire all the UDI device drivers in the UDI-BIOS in such a way as to link them directly into the main OS so that they can be used in a more efficient way, thus enabling their use in a multiprocessor environment.

I don't know if that would be possible with UDI, but in principle it could certainly be done with a package of device drivers designed to work in such a system. If UDI drivers don't limit the design of an OS heavily, then there's a good chance that UDI would fit the bill and that a community project called UDI-BIOS would be viable.

[Love4Boobies]

Sounds like a boot loader and many OSes that implement UDI. Here's an alternative design: a boot loader and many OSes that implement UDI.

[DavidCooper]

I didn't realise bootloaders were so capable - I'd always assumed they were just bootloaders.

Is there a bootloader out there which offers the equivalent of VESA 3.0 hardware scrolling and tripple buffering for smooth animation on an EFI-only machine? Is there a bootloader out there which would allow you play a WAV file? There are all sorts of things that could be built into the UDI-BIOS system which would offer any OS instant access to all manner of capabilities which are hard to get otherwise, the limiting factor being that you'd have to "stop the world" (Brendan's term) to use some of them (stopping every other process running in the machine while playing a sound file, for example); but you would also be able to decouple the drivers form the UDI-BIOS and tie them directly into your OS in such a way that you no longer have to stop the world to use them. If bootloaders already offer that kind of capability, point me to one and I'll consider using it. I thought they were just boring loaders.

[Rusky]

How about going further: firmware, a bootloader, and many OSes that implement UDI?

That would solve the problem EFI claims to solve but without not-solving it.

[Love4Boobies]

Is there a bootloader out there which offers the equivalent of VESA 3.0 hardware scrolling and tripple buffering for smooth animation on an EFI-only machine? Is there a bootloader out there which would allow you play a WAV file? There are all sorts of things that could be built into the UDI-BIOS system which would offer any OS instant access to all manner of capabilities which are hard to get otherwise, the limiting factor being that you'd have to "stop the world" (Brendan's term) to use some of them (stopping every other process running in the machine while playing a sound file, for example); but you would also be able to decouple the drivers form the UDI-BIOS and tie them directly into your OS in such a way that you no longer have to stop the world to use them. If bootloaders already offer that kind of capability, point me to one and I'll consider using it. I thought they were just boring loaders.

No, fortunately, there is no such boot loader. The boot loader is the boot loader and the driver interface (which covers things like graphics) is the driver interface. You're trying to take both of them and shove them in the firmware without any purpose. For your sake I ignored the bit regarding the WAV file (since that would also imply shoving file system support and libraries in the firmware---basically a whole OS).

All the pieces are already there. All you're doing is to rearrange them in ways in which they don't logically belong.

[DavidCooper]

No, fortunately, there is no such boot loader. The boot loader is the boot loader and the driver interface (which covers things like graphics) is the driver interface. You're trying to take both of them and shove them in the firmware without any purpose. For your sake I ignored the bit regarding the WAV file (since that would also imply shoving file system support and libraries in the firmware---basically a whole OS).

All the pieces are already there. All you're doing is to rearrange them in ways in which they don't logically belong.

What I'm describing is an auxiliary operating system, as I stated earlier. None of it would be shoved into firmware - the whole thing would be sitting in RAM and be relocatable so that the main operating system (which may be the smaller and simpler of the two) can put it where it wants it. ACPICA could be built into the auxiliary operating system as well. It wouldn't need a filesystem to play WAV files - the main OS would be able to send the raw WAV data to an auxiliary operating system routine which sends it on through the appropriate driver to produce the sound.

No community operating system project will get anywhere because people have such different ideas about how they want to organise things, but a community auxiliary operating system which is compatible with a multiplicity of main operating system designs might actually be able to get somewhere. What I'm talking about is a standard way of doing all the boring stuff while leaving individuals practically full control over the design of their own main OS to run alongside the standard auxiliary OS, in much the same way as an old real-mode OS could work in conjunction with the standard BIOS. Any capability added to the auxiliary OS would immediately be available to the designer of any main OS that works with it.

So, it isn't a whole OS, but it certainly would become a massive great chunk of an OS. It might even be possible for it to be designed from the outset to work in a multiprocessing environment so that there is no need to "stop the world" to use any part of it provided that the main OS design isn't too way-out.

[Love4Boobies]

What I'm describing is an auxiliary operating system, as I stated earlier. None of it would be shoved into firmware - the whole thing would be sitting in RAM and be relocatable so that the main operating system (which may be the smaller and simpler of the two) can put it where it wants it. ACPICA could be built into the auxiliary operating system as well.

I'm still waiting for you to explain why this auxiliary OS is useful. You just took the driver interface and power management support out of the main OS and put them in what you call an auxiliary OS. Why don't you also create a second such auxiliary OS to provide a validating XML parser and TCP/IP support? So far, I see the following disadvantages:

• A lot of work needed for no apparent gain, esp. in order to cover all corner cases (e.g., Should the binary blob be compiled for a flat memory model? Should there be a whole bunch of binary blobs for all the modules or should there be a startup compiler with the ability to cache the blobs on a per-machine basis?).
• It would be less flexible than having the OS developers port ACPICA and udiref or whatever. One can modify the source code so that it can better fit the OS' design but modifying binary bolbs is an entirely different story...

I would now like for you to put together a list of advantages. All you've done so far was to describe how the thing would work; it's time to describe why. No better way to convince people that pro/con lists.

It wouldn't need a filesystem to play WAV files - the main OS would be able to send the raw WAV data to an auxiliary operating system routine which sends it on through the appropriate driver to produce the sound.

If you don't mean files then don't say files.

Finally, to demonstrate that you're not the kind of guy who thinks a design though, I'll give you a better goal for your project: An open source bare bones OS that implements ACPICA, udiref, and whatever else you think is useful. No more need to relocate anything and thus create startup overhead, no more design compatibility problems, no more flexibility problems, and a much cleaner design. People can just work on top of the building blocks provided by this project.