DragonFlyBSD is possibly the next big thing for Apple
Check it out. This is a really amazing project. I would not be surprised at all to see this integrated into a future version of Mac OS X.
DragonFlyBSD is basically built around a messaging system. A program sends data to a port (with a return address), and waits for a reply. Devices are turned into VM objects and use the messaging system to send/recieve data.
Multiple versions of libraries can be installed, and programs only see the ones that match the environment they are compiled in.
The Light Weight Kernel Threading model looks like... wow... goodbye Mach/XNU. It rules.
"It is a goal of this [UserAPI] project to (1) make all actual system calls message-based, (2) pass structural information through capability and element lists instead of as raw structures, and (3) implement a generic 'middle layer' that looks kinda like an emulation layer, managed by the kernel but loaded into userspace. This layer implements all standard system call APIs and converts them into the appropriate message(s). For example, linux emulation would operate in (kernel-protected) userland rather then in kernelland." more backward compatibility, less hassle for programmers (and more programs).
And they save the best till last. A new VFS. This is... wow. It might be slower (initally) than Mac OS X's, but at least this works. And how.
Barto
DragonFlyBSD is basically built around a messaging system. A program sends data to a port (with a return address), and waits for a reply. Devices are turned into VM objects and use the messaging system to send/recieve data.
Multiple versions of libraries can be installed, and programs only see the ones that match the environment they are compiled in.
The Light Weight Kernel Threading model looks like... wow... goodbye Mach/XNU. It rules.
"It is a goal of this [UserAPI] project to (1) make all actual system calls message-based, (2) pass structural information through capability and element lists instead of as raw structures, and (3) implement a generic 'middle layer' that looks kinda like an emulation layer, managed by the kernel but loaded into userspace. This layer implements all standard system call APIs and converts them into the appropriate message(s). For example, linux emulation would operate in (kernel-protected) userland rather then in kernelland." more backward compatibility, less hassle for programmers (and more programs).
And they save the best till last. A new VFS. This is... wow. It might be slower (initally) than Mac OS X's, but at least this works. And how.
Barto
Comments
- Some problems this thing solves are solved by MacOS X, but differently (Mach is a message-passing kernel too, MacOS X can provide different versions of a given Framework depending on the application).
- Seems mostly useful for massive multiprocessing systems. It will be a while until we see those with MacOS.
- They just started. Will take some time until they have a working BSD.
Originally posted by madmax559
www.qnx.com
Even better...sounds a lot like Plan 9...
Very bold goals for an upstart. This project is dead in the water.
Originally posted by Eugene
Even better...sounds a lot like Plan 9...
Very bold goals for an upstart. This project is dead in the water.
er qnx has been around for a loonnng time...you use
it everyday without realizing it
dragonfly is simply exploring new avenues & some of the
smp lock changes & lightweight threads will make their
way into freebsd over a period of time..
Originally posted by torifile
It's forking off from BSD 4.x. Apple's already implemented BSD 5.x. I don't think they're going to go backwards.
I don't mean that this will be in 10.4. And if it does go into Mac OS X, it will be a big change for the Mach/XNU side of Darwin, not the FreeBSD side.
It will take "multiple years" for this project to be ready for prime-time. But when it is, this could be a big change to Mac OS X.
Barto
Originally posted by madmax559
er qnx has been around for a loonnng time...you use
it everyday without realizing it
dragonfly is simply exploring new avenues & some of the
smp lock changes & lightweight threads will make their
way into freebsd over a period of time..
Plan 9 has been around even longer, though it's nowhere near as refined or useful for industrial application. Plan 9 was purely a research project and is no longer in development.
DragonFly sounds a lot more like publicity rather than substance, and I figure as you have...all the concepts they mention will eventually find themselves in an official FreeBSD branch, with no help from the bug...