Linked by Thom Holwerda on Mon 17th Sep 2012 16:56 UTC, submitted by Andy McLaughlin
OSNews, Generic OSes "Visopsys (VISual OPerating SYStem) is an alternative operating system for PC-compatible computers, developed almost exclusively by one person, Andy McLaughlin, since its inception in 1997. Andy is a 30-something programmer from Canada, who, via Boston and San Jose ended up in London, UK, where he spends much of his spare time developing Visopsys. We had the great fortune to catch up with Andy via email and ask him questions about Visopsys, why he started the project in the first place, and where is it going in the future."
Thread beginning with comment 535542
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: The hardest part
by Brendan on Tue 18th Sep 2012 04:12 UTC in reply to "The hardest part"
Brendan
Member since:
2005-11-16

What we need is some kind of universal driver standard that can be shared across all operating systems. Ideally this would be in source form and the layer could be optimised away by the compiler. This way a driver wouldn't be written for "Windows X" but instead for the "2012 PC driver standard". The OS would implement the standard and immediately support numerous compatible hardware devices. It's a pipe dream though. For it's part, MS would never participate, and their cooperation would be pretty much mandatory.


This has been attempted several times before. The most popular attempt was UDI (Uniform Driver Interface), which failed despite being backed by several large companies (including Sun/Solaris).

Some OSs (e.g. Linux) had religious objections ("OMG what if we wrote drivers and Microsoft could use them!"), some OSs had security problems ("OMG binary blobs created by unknown third-party developers running at the highest privilege level because our kernel is monolithic!"), and some OSs had technical reasons for not using it (e.g. very different driver interfaces, capabilities and feature sets). The end result was that very few people wrote drivers for it because most OSs didn't support it (and then OSs that didn't have religious, security or technical reasons for avoiding it didn't bother supporting it anyway because there weren't many drivers).

The ancient BIOS services are not acceptable because they're single-tasking synchronous interfaces (e.g. your OS freezes while the firmware waits until a DMA transfer completes). For exactly the same reason, UEFI is not an acceptable answer either. For a decent OS, you want to be able to be transferring data to/from disk while transferring data to/from network while transferring data to/from sound card while transferring data to/from USB; where the CPUs are all still free to do unrelated/useful work (and aren't stuck in a "while(waiting) {}" loop).

- Brendan

Reply Parent Score: 2

RE[2]: The hardest part
by Alfman on Tue 18th Sep 2012 05:30 in reply to "RE: The hardest part"
Alfman Member since:
2011-01-28

Brendan,

Those are great points. I'm not under any delusions that it would be easy to get everyone on board the shared driver model. Even if we managed to solve all the technical issues, I think many corporations would reject it on account of them benefiting from high barriers to entry in the field of alternative operating systems. So I'm really very sceptical myself that we could pull it off in this day and age when computers are only getting more closed rather than more open.


Never the less, I still like dissecting the theory and appreciate your critique.


1. "Some OSs (e.g. Linux) had religious objections ('OMG what if we wrote drivers and Microsoft could use them!')"

Well, presumably the manufacturers would be on board (if they weren't the model would be bound to fail anyways). This means the manufacturers would be providing the drivers and that they would run on linux, visopsys, hurd, etc. as well as windows.


2. "some OSs had security problems ('OMG binary blobs created by unknown third-party developers running at the highest privilege level because our kernel is monolithic!')"

This is true. In principal I don't object to requiring source code with drivers, but that's not a very realistic sale. Many linux distros already have proprietary blobs, and nobody would be forced to install those. On the one hand, the high availability of shared manufacturer drivers could decrease the incentive of volunteers to write open source drivers for the same hardware. On the other hand, these volunteers could put their time to much better uses instead of reinventing the wheel.

Ultimately though if you don't trust the manufacturer of your hardware to write stable/trustworthly software, then arguably you've got no business installing their hardware on your machine either.


3. "and some OSs had technical reasons for not using it (e.g. very different driver interfaces, capabilities and feature sets)."

This is indeed probably one of the more controversial aspects, but the way I see it the drivers should be as modular as possible to make it easy to hook them into however the OS needs them. At the extreme, all operating systems today have no choice but to work with fixed interfaces anyways (ones provided by the hardware). Moving this into software shouldn't be that much of a burden to a system's design. Like I said earlier, *ideally* this wrapping layer would be in a kind of source form and it's overhead could be optimised away when it's compiled&linked with callees within the OS.


"The ancient BIOS services are not acceptable because they're single-tasking synchronous interfaces (e.g. your OS freezes while the firmware waits until a DMA transfer completes)."

Great observation. Clearly these would have to be asynchronous. Also, all device drivers should be able to run in parallel on SMP. Which is a reasonable requirement assuming they don't share resources.

Just a note: many linux drivers themselves were subject to the big kernel lock until recently, which caused similar driver serialisation bottlenecks.
http://lwn.net/Articles/380174/


I wish there would be a viable market for this, it is a project I think I would enjoy working on.

Edited 2012-09-18 05:38 UTC

Reply Parent Score: 4

RE[3]: The hardest part
by Brendan on Wed 19th Sep 2012 11:55 in reply to "RE[2]: The hardest part"
Brendan Member since:
2005-11-16

1. "Some OSs (e.g. Linux) had religious objections ('OMG what if we wrote drivers and Microsoft could use them!')"

Well, presumably the manufacturers would be on board (if they weren't the model would be bound to fail anyways). This means the manufacturers would be providing the drivers and that they would run on linux, visopsys, hurd, etc. as well as windows.


Almost all hardware manufacturers only care about Windows; and like you already said, Microsoft has nothing to gain from adopting this. The rare few manufacturers that do care about anything else (NVidia, ATI/AMD, Intel) only care about Linux. Linux developers (and GNU specifically) are the people that refused to support UDI for religious reasons ( http://www.gnu.org/philosophy/udi.html ).

2. "some OSs had security problems ('OMG binary blobs created by unknown third-party developers running at the highest privilege level because our kernel is monolithic!')"

This is true. In principal I don't object to requiring source code with drivers, but that's not a very realistic sale. Many linux distros already have proprietary blobs, and nobody would be forced to install those. On the one hand, the high availability of shared manufacturer drivers could decrease the incentive of volunteers to write open source drivers for the same hardware. On the other hand, these volunteers could put their time to much better uses instead of reinventing the wheel.


Linux has some binary blobs; but they don't like it and would get rid of them if they could. It'd be extremely hard to convince them to replace existing/working open source drivers with alternative (potentially closed source) drivers.

Ultimately though if you don't trust the manufacturer of your hardware to write stable/trustworthly software, then arguably you've got no business installing their hardware on your machine either.


It's not the hardware manufacturers that would be writing drivers. It's people volunteering their time to slap together something that "works for me(tm)".

3. "and some OSs had technical reasons for not using it (e.g. very different driver interfaces, capabilities and feature sets)."

This is indeed probably one of the more controversial aspects, but the way I see it the drivers should be as modular as possible to make it easy to hook them into however the OS needs them.


In this case, people/volunteers will only write the modules for the OS they care about and the driver won't work on any OS that needs different modules.

At the extreme, all operating systems today have no choice but to work with fixed interfaces anyways (ones provided by the hardware). Moving this into software shouldn't be that much of a burden to a system's design.


A driver is a kind of abstraction layer between whatever interface the OS wants and whatever interface the hardware provides. What you're talking about is having drivers that provide an unwanted interface, with a "driver driver" between the unwanted interface and the OS itself.

Like I said earlier, *ideally* this wrapping layer would be in a kind of source form and it's overhead could be optimised away when it's compiled&linked with callees within the OS.


Trying to get different developers to agree on a common device driver standard will be hard. Trying to get different developers to agree on a common programming language is going be even harder.

"The ancient BIOS services are not acceptable because they're single-tasking synchronous interfaces (e.g. your OS freezes while the firmware waits until a DMA transfer completes)."

Great observation. Clearly these would have to be asynchronous. Also, all device drivers should be able to run in parallel on SMP. Which is a reasonable requirement assuming they don't share resources.


Not just asynchronous, but "asynchronous with IO priorities". For example, you should be able to say "pre-fetch these sectors as low priority" and also say "change the priority of my earlier request (I need them sectors ASAP!)" or "cancel that request, I don't need those sectors now".

Not just different drivers running at the same time, but the same driver being able to complete multiple requests at the same time (e.g. if there's some sort of sector cache or something) and accepting new requests while existing requests are being performed.

Of course this is just the tip of the iceberg (e.g. I was only really looking at some aspects of storage device drivers). If you want to look at something like video driver interfaces then the sheet really hits the fan.

I wish there would be a viable market for this, it is a project I think I would enjoy working on.


A lot of people wish it was viable. Some try to do it (UDI, EDI/Extensible Device Interface). It hasn't worked yet.

I'm not necessarily saying it's impossible though - just very unlikely to become widespread.

- Brendan

Reply Parent Score: 2