Ecrid Phris Posted January 17, 2008 Share Posted January 17, 2008 Sorry for this noobie questions... I was wondering, since leopard is UNIX certified, can we use drivers from LINUX or other *NIX OSes ? Is there a way to use such a thing? Can we just grab drivers from LINUX or other *NIX OSes ? If it can be used, I'm imagining that Leopard can be installed on every Machine that can run LINUX or other *NIX OSes... Once again sorry for this too noobie questions... Ecrid Link to comment Share on other sites More sharing options...
lewellyn Posted January 18, 2008 Share Posted January 18, 2008 (Long post. Short answer at end. Reading it may be edifying, however. Note that there are gross over-simplifications and terrible analogies in this post. It is hoped that these will introduce the concepts without misinforming the reader. This post will not get into licensing issues. ) At first blush, you'd think "UNIX is UNIX". But, that doesn't mean binary compatibility. Not even source code compatibility, really. (Especially in the case of wannabe-UNIX. i.e. Linux.) Though there have been attempts to standardize running applications across different UNIX platforms, this proved difficult enough (technically and politically) that there were never any successful attempts that I know of to try this on a kernel driver level. See also: What is UNIX? If you could simply take your FreeBSD driver and drop it into your OS X box to make it recognize some nifty new piece of hardware, life would be both easier and harder. It'd be easier on everyone as you'd have "write-once-run-anywhere": the Holy Grail of computing. But, it'd be harder on everyone as: 1) Bug hunting would be more difficult; 2) who do you blame when a driver fails on just one UNIX?; 3) there'd have to be a standardized kernel module interface. Points 1 and 2 seem obvious enough, so I'll skip them. 3, however, may require a bit of thought. Newcomers to the land of UNIX are inundated with a battlefield of Holy Wars. The first many come across is KDE vs GNOME (vs CDE vs XFCE vs twm vs olwm vs …), followed by vi vs emacs, C vs C++, Python vs Perl, wxWindows vs QT vs GTK, and so on… (Is lp vs CUPS dead yet? How about NFS vs Samba? I think big-endian vs little-endian's dead for most users now, right?) Luckily, on a Mac, most of these holy wars have been decided for you (but that doesn't stop them from being resurrected; it's more like an imposed cease-fire…). There's another holy war that many people are happily oblivious to, but is at the heart of Linux's history: monolithic kernel vs microkernel. If you're curious as to how such an "obscure" thing is at the heart of Linux (note that I do NOT mean "GNU/Linux" here; read on and you'll see another mention of GNU!), you will want to research the history of Minix and Linux. The subject is also a key piece of Apple's OS history, but that's a lengthy post in itself! First off, what, exactly, is a kernel? Well, at its core, it's the "actual" operating system. Think of it as the coach of a sports team, the successful hands-on CEO of a company, or something similar. It is, essentially, what makes the system boot and work. OK. What's a microkernel then? It sounds small, so it must be the easier one to explain! Well, essentially, a microkernel is a program which (ideally) only provides "interfaces" or "services" to allow other programs ("drivers") to do the heavy lifting. It sits back and allows things to talk to each other and manages memory. Probably reminds you of the stereotypical union job-site foreman: Paid handsomely and doesn't visibly work; but his absence will make everything halt. The microkernel evolved from the natural growth of UNIX and the need for security and easy code management. (Though, most microkernels aren't used for UNIX systems. The most notable currently-used microkernels are probably the ones in OS X, QNX, GNU/Hurd, and Minix. Think of it as "learning from others' mistakes". ) While it's possible to bring down a microkernel, ideally you only lose the offending driver. (Ever had a device just "stop working" on Windows or OS X, which was fixed by a reboot and never happened again? Good chance the driver crashed. On Linux or *BSD, there's a good chance another driver would have been corrupted in that case, and you would have had a crash or, at best, a need to reboot immediately.) So, what's a monolithic kernel? Well, if a microkernel's a jobsite foreman, a monolithic kernel's a schoolyard. It's big, everything can trample all about (though there's usually someone/something trying to keep order!), and if one thing fails, chaos can ensue. (Remember how the whole schoolyard rushed to the scene of a fight, and how the "adults" had a hard time working their way into the crowd to take control? Well, a driver crash can cause a deadlock in a monolithic kernel far more easily than in the average microkernel.) Also, in a monolithic kernel, the drivers "share" their address space. And, again, when kids "share" things, if one's sick, they all can get sick and quickly! However, it's not all bad. Things tend to "just work", and everything just gets along. But the "kernel" in this case comprises the schoolyard and everything on it, as opposed to "just" the foreman of a jobsite. (To keep the analogies straight.) (There are other types of kernels, such as a "hybrid" kernel as utilized by NT, and exokernels, but for the purposes of this post, they're easily swept into the "microkernel" category.) Now that we know WHAT a microkernel and a monolithic kernel are, why do we care? Well, most obviously, they stem from hugely different design ideas. There's no way that one can generally just take the source code from a monolithic kernel and drop it into a microkernel (or vice versa), without heavy modification. Even between microkernels, this can be a challenge, as while they may share design philosophies, the methods used can differ wildly. Certainly, there are many drivers which have been ported between Linux and BSD (BSD is a monolithic kernel, like Linux). But even these ports aren't necessarily "easy". Now, imagine having to do the same across totally different design philosophies. And this is why we care: OS X is a microkernel. In most cases, the best you can do is "crib" what the existing driver is doing, and implement it yourself. Needless to say, in most cases, if you have access to specifications, you can probably implement a driver faster from scratch than trying to take one from a totally foreign operating system. (Even if they're both "UNIX".) Sadly, most devices don't have publicly available specifications. So, driver writers for open-source drivers are forced to use trial-and-error, crib how similar drivers do things (on the same OS and on others), and bang their heads on their desks over and over. A notable example is nForce ethernet. There are currently 2 (that I know of) semi-active attempts to write a "working" driver for this beast. Both attempts are "semi-working" for most users, "fully working" for very few, and don't "work" for quite a number. Both attempts also attempt to re-use existing code (both use "forcedeth", at least its framework). And even with this re-use, there has been much need for original code to be created. Hopefully, one or both will eventually be "done", and then they, ideally, could themselves be used as "frameworks" for other ethernet drivers, speeding up other "ports". So, long answer short: "No, you can't use drivers from other operating systems. Sorry." P.S. I was going to use a schoolbus analogy instead of a schoolyard analogy. But I thought that having the bus drive off a cliff may not go over well... Link to comment Share on other sites More sharing options...
Ecrid Phris Posted January 18, 2008 Author Share Posted January 18, 2008 Wow... A long reply indeed... But lewellyn, you really opened my mind... I got used to using windows, where there are standards for every driver (Well, made by their respective vendor...) I really thought that the base system of those *NIX OSes are the same... Since you know, a couple terminal command are the same... Like sudo, chown, etc... Then, can we get a grasp of how a driver of a hardware would work, by looking at a driver of the same model in another OS (Such as linux OS)? Maybe the logic of those hardware driver are the same... I really wanted to try to make a driver, do you happen to have a reference? I really am a noobie in these kind of thing... No idea where to start... Really... Thanks for your shared of knowledge... Ecrid Link to comment Share on other sites More sharing options...
Eddie Turfboer Posted January 18, 2008 Share Posted January 18, 2008 I really thought that the base system of those *NIX OSes are the same... That was striking for me as well! Never thought that UNIX =not UNIX. Ow, if you are trying to write a driver, can you write one for me as well? It is a Creative X-Fi sound card? Thanks Link to comment Share on other sites More sharing options...
Megamixman Posted January 18, 2008 Share Posted January 18, 2008 Unix is more of a standard now. No where does it define that a driver has to be implemented in a certain model or manner. Don't forget modern day Linuxes are not made by 1 group/person/entity. There are several groups that work independently of each other. The thing that brings them together is the fact that they all use the linux kernel, which more or less defines how drivers work. BSD is more like Unix in that it is a standard. The major BSDs all make their own kernel, but the BSD standard as a much more well defined driver model that drivers can be ported over relatively easy in comparison to the linux to bsd port. The problem with your comparison to windows is that windows is made by 1 company and it has to keep backward compatibility for it's product. As you can see Unix based OSes are not made by 1 company and they don't have a customer base that demands a high level of backwards compatibility ( although it is nice and they do provide it ). Link to comment Share on other sites More sharing options...
lewellyn Posted January 19, 2008 Share Posted January 19, 2008 Megamixman, BSD isn't "like UNIX", it is UNIX. (Just like OS X, Solaris, AIX, UnixWare, and many others…) Linux is not a UNIX. Some day, it may actually apply for UNIX certification, but there be dragons there! Ecrid, on Windows, the different kernels used require different drivers, as well... For example, you can't stick a Windows 3.1 video driver on Vista. Heck, I don't think even a Windows 2000 driver would work! For Windows, there are 3 major kernel "families": Win 3.x (we'll sweep 1.x and 2.x under the rug for this, since even 3.x is ancient history), 4.x (aka "9x"), and NT (NT 3.1-Vista). It's just the long lifetime of each OS version that keeps the driver writers supporting the appropriate systems indefinitely, and transparently… If you're really thinking of tackling the task of writing a driver, first get comfortable in Xcode. It's different from most other IDEs (unless you developed on a NeXT in the past, maybe…), so if you have issues getting simple stuff working, writing a driver is going to be impossible. After you've gotten the hang of general tasks in Xcode, grab the Darwin source code (OS X is essentially a BSD called "Darwin", plus fancy graphics stuff). Then, sit down with the ADC IOKit docs and the Darwin sources and see how the drivers "tick". Maybe make some simple modifications to add debugging to a driver you use often (maybe USB?). Once you get the hang of that, then you'll probably have an idea of what lies ahead for writing from scratch. And, keep in mind licensing when you write your driver! If your driver's going to be non-GPL licensed, you can't even look at the source to the Linux driver. (This is called "tainted code", when you violate licensing.) However, if you come up with a new and novel driver that may get you fame, fortune, and a place at a major corporation, you may find that something like a BSD license is appropriate, as it allows binaries to be distributed without their sources. And, if you think your code's just hideous, you can always say "here's the .kext, the source is mine"! But just remember to not taint your code. I'd hate for someone to get upset at you and sic their lawyers upon you! (I think the GPL is now considered "legally enforceable"…) I wish you the best of luck in your adventures! And, it seems that some of the prominent members of this community are quite willing to lend a helping hand if you've proven that you're on the right track. So, don't get too discouraged if you make it through modifying a driver, but have issues with writing your own! Link to comment Share on other sites More sharing options...
Megamixman Posted January 20, 2008 Share Posted January 20, 2008 OK, lets get this straight. Unix was an OS made in 1969 by Bell Labs. BSD was Unix-Like OS made by UC Berkeley. Both were OSes. Neither are in particular use today. What we have today are OSes that adhere to the standards of Unix and BSD. So no, BSD is not Unix and Unix is not BSD. But BSD does adhere to the Unix Standard that today is considered to be Unix, although it really isn't. Link to comment Share on other sites More sharing options...
lewellyn Posted January 20, 2008 Share Posted January 20, 2008 OK, lets get this straight. Unix was an OS made in 1969 by Bell Labs. BSD was Unix-Like OS made by UC Berkeley. Both were OSes. Neither are in particular use today. What we have today are OSes that adhere to the standards of Unix and BSD. So no, BSD is not Unix and Unix is not BSD. But BSD does adhere to the Unix Standard that today is considered to be Unix, although it really isn't. Well... Unix became "UnixWare" and is at the heart of the famous SCO lawsuit. BSD started off as a variant of Unix, a collection of patches. A "fork", if you will. FreeBSD (and company) derive from the BSD branch of AT&T's UNIX, through 386BSD and 4.4BSD. This makes BSD-based Unix a "hereditary" UNIX. The only widespread "hereditary" UNIX systems in wide use these days would be the various BSDs (including OS X) and Solaris. (Though many others are still used on big boxes!) Linux, on the other hand is a "clone" of UNIX (or more accurately, an implementation of POSIX). Vista's got a fairly complete POSIX subsystem, too, in the Ultimate edition… But the actual heredity of UNIX is irrelevant. The differences between operating systems (from a driver perspective) are in the kernels. It is arguable that you'd get further by taking a device with truly open-source drivers on Windows and FreeBSD and using those as hints for writing an IOKit driver than taking a Linux or Solaris driver and using it. (My understanding, bearing in mind that I'm not a kernel hacker of any repute, is that the NT driver model is somewhat similar to IOKit, in comparison to a Unix or Linux driver model.) But the key is to first learn the development environment, then start worrying how you're going to code the thing. And, in any case, binaries aren't the same across systems (ignoring iBCS and such). So, just as you can't take a Linux binary and run it on your Mac, you can't take a driver (which requires system-level coordination to run) and expect it either. Link to comment Share on other sites More sharing options...
Ecrid Phris Posted February 4, 2008 Author Share Posted February 4, 2008 Great explanation Lewellyn ! But do u know, that some of Windows 2000 driver works on XP... Well some of it... Thanks for your info... I think I need to learn more before writing a driver... I'm planning to make my Toshiba R10 do OSX... But there are a couple of bugs, and since I'm doing my final in my uni, can't have an unstable system yet... Maybe I'll search for info on how to make a driver for it... (The wireless and network card driver)... Then I might begin doing this driver business in May... Ecrid Link to comment Share on other sites More sharing options...
Gravisman Posted December 12, 2008 Share Posted December 12, 2008 "And this is why we care: OS X is a microkernel" Despite the eloquence, this is simply not true. Don't make the common mistake of confusing a modular kernel with a microkernel. OS X's xnu kernel is certainly modular - that is, its components are broken up into many distinct modules with specific responsibilities. There's BSD, IOKit, Mach, and more, and these things are all part of the kernel. That all those things are part of the kernel is exactly why xnu is NOT a microkernel - it is undoubtedly monolithic. That is, pretty much everything runs inside the one kernel_task and its many threads. There are a few user-space daemons that OS X uses, but not nearly enough to classify it as using a microkernel. As I said before, modularity != microkernel. What makes a microkernel is to have a kernel that only provides the most fundamental OS functions, and everything else can be handled by processes running outside the kernel - what is typically referred to as "user space." These fundamental functions are things like scheduling, IPC, and memory management. In OS X, these are things provided by Mach, which could be considered a microkernel. Only problem is that Mach is only one part of the xnu kernel. If OS X shrunk its kernel down to the size of Mach and moved everything else outside the kernel, then we could say it's a microkernel, but that's not the case. The reality is that while microkernels look great on paper, in today's world they exist primarily in the minds and papers of academics. This is because they're actually more difficult to program (it's sort of easier to just throw everything into one giant program). As such, no major OS can be said to use a microkernel at this point. OS X, Linux, and Windows all employ monolithic kernels. Link to comment Share on other sites More sharing options...
Slice Posted December 12, 2008 Share Posted December 12, 2008 "monolitic" but "broken up into many distinct modules" The answer to topic is "NO, Linux drivers can't be ported to MacOS X" Link to comment Share on other sites More sharing options...
Recommended Posts