| News | Features | Interviews |
| Blog | Contact | Editorials |
| Visopsys: one man's vision to build an operating system |
| By Thom Holwerda, submitted by Andy McLaughlin on 2012-09-17 16:56:46 |
| "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." |
|
| RE[2]: The hardest part |
| By Alfman on 2012-09-18 05:30:50 |
|
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 |
 - Score: 4 |
| Great piece |
| By jido on 2012-09-18 06:12:42 |
| Thanks for linking to the article. Really inspirational. |
| - Score: 2 |
| RE: The hardest part |
| By aargh on 2012-09-18 07:28:09 |
|
> What we need is some kind of universal driver standard that can be shared across all operating systems. You mean like Genode? Now, why hasn't someone already thought of that... |
| - Score: 1 |
| RE: The hardest part |
| By Laurence on 2012-09-18 08:03:56 |
|
That's a great idea in theory, but wouldn't it push kernels into a more hybrid or even -dare I say it- micro kernel design? Without wanting to get into a debate about micro vs monolithic kernels; if a unified driver format meant constraints on the design then I could see a lot of potential advocates turning their back on said driver format. Particularly those who have a monolithic kernel (Linux being the biggest loss). I guess, even if the above supposition was correct (and there's a very good chance I'm talking complete BS here lol), then at least a unified format could offer "fall back" drivers for occasions when optimised / native kernel drivers are not available (much like the aforementioned VESA mode - which is invaluable for setting up servers) |
| - Score: 2 |
| RE[2]: The hardest part |
| By Laurence on 2012-09-18 08:16:59 |
|
> > What we need is some kind of universal driver standard that can be shared across all operating systems. You mean like Genode? Now, why hasn't someone already thought of that... Genode isn't really a universal driver standard though. In fact, I'm still not 100% certain what Genode is setting out to achieve even after (loosely) following the project for a few years. but from what I can gather, it's a complete micro kernel architecture design to allow running guest kernels (such as Linux) and thus their drivers. |
| - Score: 2 |
| RE: The hardest part |
| By Vanders on 2012-09-18 10:44:42 |
|
> ...all interpreting the standards in their own ‘unique’ ways. You might write something like an IDE driver that works on every system you try, release it, and then find out it isn’t working properly on hundreds of other peoples’ systems IDE? All. My. Hate. I often said that it appears every single manufacturer of an ATA controller took the specification, had it translated into Japanese by a 13 year old Spanish teenager and then handed it to a Brazilian programmer to read out loud to a Polish developer as he tried to implement it. I have no other explanation for how hardware designers could all come to such odd interpretations of something that was supposedly a written standard. |
| - Score: 2 |
| RE: Pretty interesting. |
| By Laurence on 2012-09-18 13:46:48 |
|
> I wish there was a better virtualization program for Linux... VirtualBox seems too damn buggy and causes nothing but problems. Over the years, it still is a pain in the ass. You mean apart from VMWare, Xen and KVM? You could even run qemu from the desktop, if you just wanted pure hardware emulation without any kernel optimisations. |
| - Score: 2 |
| RE[2]: The hardest part |
| By Alfman on 2012-09-18 16:03:11 |
|
Laurence, "That's a great idea in theory, but wouldn't it push kernels into a more hybrid or even -dare I say it- micro kernel design?" I don't think so, but it's worth investigating. Linux can call VESA or UEFI without becoming more hybrid (note that's not the exact model I'm proposing per-say, but I never the less think it's a valid counter-example). Actually my gut instinct is to say the opposite may be more of a concern, how would a microkernel incorporate these drivers? Obviously the microkernel's goal is to isolate the drivers from one another, would it be able to jail the drivers and still have them work? That depends how they're written. The standard would have to be very clear about how drivers could interact with the system, no direct manipulation of GDT or interrupt tables, drivers would need to request permission to access ports instead of assuming they're running in ring-0. They'd need standard ways to coordinate memory mapping. These murky details all need to be ironed out for sure, but with a well defined standard, a good reference implementation, a robust test suite, and a certification process, then we should have quality drivers that work everywhere without worrying about OS-specific quirks. I don't think an existing operating systems would need too many changes (assuming it's drivers were already modular and self-contained). It wouldn't be too different from writing a new OS-specific driver for a new piece of hardware, only this particular OS-specific driver will be capable of driving all hardware supported by the shared driver standard. Edited 2012-09-18 16:07 UTC |
| - Score: 2 |
| RE: Comment by benb320 |
| By Lennie on 2012-09-18 16:55:14 |
|
The article mentions: "University in Calgary Canada" So maybe he is from the west coast ? |
| - Score: 2 |
| RE[5]: The hardest part |
| By zima on 2012-09-18 17:35:08 |
|
> I have yet to own a webcam where windows drivers weren't necessary...but then it's a noname brand. If what you are saying is true and they are becoming standardised, that's a very welcome change! "if"? They're out there, for better part of a decade ( http://en.wikipedia.org/wiki/USB... & when I was shopping for a webcam 5 years ago or so, there were certainly some USB video class models available; few on http://en.wikipedia.org/wiki/Lis... or http://www.ideasonboard.org/uvc/... list are at least that old) I guess some noname models might still use oldish innards, not modified for a long time ...as usual with hardware, you check if it fulfils your criteria before buying (but, if you care about such "total" plug'n'play in a webcam, how did you miss the existence of USB video class?), and/or get something very popular - hence widely supported (that example I gave, when the default Windows drivers worked better than manufacturer-provided - it wasn't even a USB video class webcam; it was about pre-UVC, but as standard as they come, classic QuickCam Express) |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |