Annoucning DragonFly BSD!
Matthew Dillon
dillon at apollo.backplane.com
Sat Jul 19 11:15:34 PDT 2003
:Matthew,
:OK, you want a divergent kernel, EG src/sys/ , fair enough.
:
: - Are there any benefits to the BSD community in having
: a 4th BSD bin/ sbin/ usr.bin/ usr.sbin/ ?
: Can you not share & co-operate with toolset maintainers of NetBSD
: or OpenBSD, even if you can't work with some FreeBSD CVS people ?
I don't think these particular subhiearchies are that big a deal.
Except for libc and libc_r, most of the above will wind up being
almost identical to their 4.x counterparts. You know the old saying...
if it aint broke...
One big part of the goal set will be the creation of a middle 'emulation'
layer which is managed by the kernel but runs in userland, which will
take over all primary system call entry points (in userland) and convert
them to syscall messages that the kernel understands. 4.x, 5.x, SysV,
Linux, and other compatibility sets will be moved out of the kernel and
into this middle layer. Even the 'native' syscall set will run through
an emulation layer (though being aware of it the native sets will call
the emulation layer directly rather then bounce through the kernel).
The advantage of this methodology is that we will be able to keep the
kernel clean. For example, we would be able to modify how certain syscall
messages work and simply by fixing the backend of the appropriate
emulation layers we can maintain binary compatibility with any past
userland. The emulation layer would be fully versioned so older
userland programs use emulation layers targeted to older APIs, and newer
userland programs use emulation layers targeted to newer APIs.
So there would no longer be five different versions of stat() in the
kernel, for example. There might be five different versions of the
'4.x emulation layer', but there would be only *ONE* stat in the kernel.
: - Do you intend your own ports/ collection too ? (or Free, Net or Open ?)
:
:-
:Julian Stacey Freelance Systems Engineer, Unix & Net Consultant, Munich.
A Packaging system is a very important piece of any distribution. Our
goal will be to create a packaging system that, via VFS 'environments',
causes any particular package to see only the dependancies that it
depends on, and the proper version of said dependancies as well. Multiple
versions of third party apps that normally conflict with each other could
be installed simultaniously. The packaging-system-controlled VFS
environment would also hide everything a package does not depend on,
like other libraries in the system, in order to guarentee that the
dependancies listed in the packaging system are in fact what the
application depends on. There's no point in having a packaging system
that can't detect broken and incorrect dependancies or we wind up with
the same mess that we have with ports.
To make this work the VFS environment would have to be able to run as
a userland process. Otherwise we would never be able to throw in the
type of flexibility and sophistication required to make it do what we
want it to do, and the kernel interfacing would have to be quite robust.
I want to make these environments so ubiquitous that they are simply
taken for granted. Begin userland VFSs with the capability of
overlaying the entire filesystem space, these environments would be
extremely powerful.
It might be possible to build this new packaging system on top of the
existing ports infrastructure. It will be several months (possibly
6-12 months) before the kernelland is sufficienctly progressed to be
able to imlpement the userland VFS concept so we have a lot of time to
think about how to do it.
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the freebsd-current
mailing list