: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>Received on Sat Jul 19 2003 - 09:15:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:15 UTC