| 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[5]: The hardest part |
| By zima on 2012-09-18 18:07:25 |
|
> I only posted that in response to the BIOS comment. I don't consider UEFI firmware a great substitute for a software driver standard It was mostly just half-joking continuation of "That's what the BIOS does. Welcome to 16-bit mode" post just above ...though UEFI did have also that goal in mind, IIRC. And which, as I said, didn't really work out - and you pointed out some possible issues with the UEFI approach. Problem is, perhaps that's one of the very few ways of achieving such total plug'n'play? The others would be a) drawing on the work of existing standard bodies (but I have some doubts if Haiku, Syllable or Visopsys support, say, even USB video class) b) drawing on the work done for the big boys (what NDISwrapper does, and ReactOS has a goal of using all standard Windows drivers IIRC; I believe there's also notable BSDs <-> Linux cross-pollination, extending also to Haiku and such). Either way, it would force more idiosyncrasies of dominant OS onto independent ones - would that be good? Cameras are also covered BTW, VoIP devices largely fall under some device class for external USB soundcards, and there was also some standard for scanners IIRC. |
 - Score: 2 |
| RE[6]: The hardest part |
| By Alfman on 2012-09-18 18:25:30 |
|
Yes, I say "if" because clearly some new webcams are not supported by windows 7 out of the box. I'm looking now at newegg and I can't tell which ones are and which are not, they don't list their usb classes or identification numbers. To be honest, I don't mind installing drivers the old-school way, it was never really a criteria for me. The only device type where not having built in drivers really hurts is network cards - since there's no way to go online and download new drivers. |
| - Score: 2 |
| RE[7]: The hardest part |
| By zima on 2012-09-18 19:00:35 |
|
But total world domination of UVC is not what I had in mind when writing "Webcams are already more or less covered, by USB video class" - for there to be no outliers, you'd have to force everybody to use UVC, and how do you propose doing that? (other than... MS becoming much more aggressive - and not only about the logo, but outright banning all non-compliant devices from Windows; I can bet you'd grumble much more about such scenario :p ). So yes, webcams following their USB class are out there and quite numerous, no need for "if" - salesmen not advertising it, and consumers seemingly not caring much, is another issue. Because it's good to have built-in drivers, or even such device class. Makes hardware more likely usable, down the line (that decade+ old QuickCam Express that I mentioned, still recognized & working flawlessly; no such luck with one similarly old and much nicer - but also rarer - Philips webcam; plus, OS-included drivers of chipsets and such often tended to be more trouble-free, in my experience) |
| - Score: 2 |
| RE[6]: The hardest part |
| By Alfman on 2012-09-18 19:23:02 |
|
zima, "Problem is, perhaps that's one of the very few ways of achieving such total plug'n'play?" I think it depends what you mean by PNP. As a hardware spec, PNP refers to the mechanisms of allocating the resources (memory, ports, interrupts, dma) for hardware and identifying it. This is mostly solved by Bios/UEFI already and I see no reason to change it. Even when no drivers are available in the OS, the system is still able to allocate device resources via PNP. I don't think there's a PNP problem for hobby operating systems in general. You keep suggesting to draw on the work of existing standards bodies, and to the extent that we can I agree it's a good idea. However I am not aware of any standards that approach the driver problem holistically and with the goal of being applied across operating systems. Your usb video class example is fine, but it falls short of solving the more general problem (even assuming all usb webcams could use this standard). Once my OS has implemented this USB standard, can I plug in any PCI frame buffer capture card and use it? Can I plug in a firewire device and capture from it? Can I plug in an eithernet/Wifi webcam device and capture from it? Can I pair to a bluetooth webcam? The answer in most cases is going to be no because the USB standard is just that, it's not intented as a generic solution to the driver problem. I want a driver solution that can continue to work even if a new bus comes along to replace USB. I want something specifically designed to solve the driver problem for all operating systems without regards to the standards of a specific bus. A second thing to keep in mind is that this driver standard should not seek to dictate how manufacturers should build their hardware. I feel they should be unrestricted to build the hardware however they want. It would be the software driver's responsibility to bridge the gap between the driver standard and the hardware interface. If needed they could add proprietary extensions until the time when the standard officially adopted those extensions. Even then, the existing hardware wouldn't need to be updated, only the drivers. This would mean the functionality defined in the standard would always be available to all operating systems, only non-standard functionality would be OS specific. "Either way, it would force more idiosyncrasies of dominant OS onto independent ones - would that be good?" Your example was taking existing drivers today (say from windows) and making them the defacto standard. That's not what I had in mind. Shared drivers would be designed from the ground up to be more agnostic. |
| - Score: 2 |
| RE[8]: The hardest part |
| By Alfman on 2012-09-18 19:44:21 |
|
zima, "So yes, webcams following their USB class are out there and quite numerous, no need for 'if' - salesmen not advertising it, and consumers seemingly not caring much, is another issue." I just had to take you at your word, I was not attempting to suggest you were wrong. "Because it's good to have built-in drivers, or even such device class. Makes hardware more likely usable, down the line (that decade+ old QuickCam Express that I mentioned..." I think the shared driver model would take care of that though. If an OS implements ONE webcam interface "2012 PC driver webcam interface", then all of today's webcams could have a driver using this interface and be compatible. A decade from now we have the "2020 PC driver webcam interface", so the hobby OS implements only that interface and cannot control 2012 drivers directly. Boohoo end of story? Not at all, there's no reason someone couldn't write a 2020 driver which, instead of interfacing to real hardware, would interfaces to the 2012 driver model and consequently load all 2012 compatible drivers. This is what I meant by forwards compatibility. This would result in a significant reduction of effort spent in hobby operating systems writing drivers, and actually result in them being immediately compatible with all hardware being sold to the general population. I won't pretend to know how to realistically get there from here, but all I know is that it would be an OS-deving paradise. Edited 2012-09-18 19:55 UTC |
| - Score: 2 |
| Beautiful. |
| By gus3 on 2012-09-18 20:17:48 |
| My friend, this belongs in the Fortunes database. |
| - Score: 1 |
| RE: The hardest part |
| By demetrioussharpe on 2012-09-19 00:10:07 |
|
> 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 already been tried; it's called UDI (Uniform Driver Interface). Unfortunately, it's exceptionally hard to get everyone on board with such an effort. The open source community largely ignored it, because it allowed the proliferation of binary drivers to continue. None of the other OS vendors had any incentive to participate in it because they don't have a problem getting manufacturers to create drivers for them. It's a shame, because there's also a reference implementation available, but no one seems to care. Perhaps all of the hobby OS's should work to create drivers for this API to allow driver sharing. If you'd like to check UDI out, here're a few links: http://en.wikipedia.org/wiki/Uni... http://www.projectudi.org/ http://projectudi.sourceforge.ne... |
| - Score: 1 |
| RE[2]: The hardest part |
| By Alfman on 2012-09-19 00:45:15 |
|
demetrioussharpe, Thank you for the links. UDI had been mentioned already, and as far as I can tell it fell into obscurity a decade ago for the political reasons that have already been mentioned. It was a good idea but I don't think it wasn't a complete solution either, only targeting system devices like network and block devices. I couldn't find anything in UDI for webcams, scanners, or even mice. To those of you who may be questioning why bother talking about this when the chance of adoption is next to none, well...I'm an os-dever at heart, I fantasize about how things should be. I suspect it's the same thing that drives people like Visopsys's creator. |
| - Score: 2 |
| RE[3]: The hardest part |
| By demetrioussharpe on 2012-09-19 03:11:41 |
|
> demetrioussharpe, Thank you for the links. UDI had been mentioned already, and as far as I can tell it fell into obscurity a decade ago for the political reasons that have already been mentioned. It was a good idea but I don't think it wasn't a complete solution either, only targeting system devices like network and block devices. I couldn't find anything in UDI for webcams, scanners, or even mice. To those of you who may be questioning why bother talking about this when the chance of adoption is next to none, well...I'm an os-dever at heart, I fantasize about how things should be. I suspect it's the same thing that drives people like Visopsys's creator. You're welcome. I'll say this, though: since UDI is defunct, there's room for someone(s) to pick up the project & create a standard for the rest of the types of devices. Going forward, this could be a worthy API for the hobby OS community to pick up & work on as an overall solution to this problem, since this will be the main showstopper that'll stop most hobby OSes from going mainstream. Just because Linux & the other main open source OSes didn't pick it up, doesn't mean that it wouldn't be a boon for other groups. In fact, this might actually level the playing field for the other OSes, since Linux seems to get most of the open source OS developer talent. |
| - Score: 1 |
| RE[3]: The hardest part |
| By Laurence on 2012-09-19 07:59:09 |
|
> 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). I'm not sure those examples are applicable as VESA is an agreed standard where each OS has incorporated their own drivers and UEFI happens outside of the OS. ndiswapper might be an applicable comparison though as that runs Windows drivers on a Linux kernel. I don't pretend to be an expert on how ndiswapper works, but from what I gather, it's quite similar to FUSE; ie it has a kernel driver but the actual imported drivers (be that ntfs-3g in FUSE or a Windows wireless driver in ndiswapper) will run in user space. I'm not sure if the same would be required if going down a totally universal driver set. Probably not. I'm not a kernel developer so not really in a position to comment hehehe > Actually my gut instinct is to say the opposite may be more of a concern, how would a microkernel incorporate these drivers? I don't really follow your line of thinking there. I'm not saying you're wrong (I really don't want to come across like I'm knowledgeable here because I'm really not!) but I'd appreciate it if you could elaborate a little more please :) > 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. I might be saying something really stupid here, so please forgive me; but if the existing architecture has drivers written in a modular / self-contained way, then wouldn't that be a hybrid kernel? I think I have a basic grasp on all this (I did experiment with writing my own kernel many years ago), but I'm definitely no more experienced than a curious n00b. So I apologise if I'm making no sense there. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |