[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Dazuko-devel] 2.3.4-pre1 posted
From: |
John Ogness |
Subject: |
[Dazuko-devel] 2.3.4-pre1 posted |
Date: |
Mon, 27 Aug 2007 22:20:10 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) |
Hi,
Today I have posted 2.3.4-pre1 of Dazuko. Here is a brief description
of each of the new items:
- LSM 2.6.23
Support for the upcoming Linux 2.6.23 LSM API has been added.
- new option "--sct-nocheck"
A new configure option has been added to disable the syscall table
checks. These are used when you are using syscall hooking with Linux
2.6. On non-x86 architectures these checks do not work correctly
(you cannot compile them). So for non-x86 architectures these checks
can be disabled.
- removed __d_path() dependency (Linux 2.6 + LSM)
For Linux 2.6 support using LSM, the dependency on __d_path() has
been successfully removed. This means that SMP machines can safely
detect chroot'd processes without requiring any special kernel
patches. Note that this is only available for LSM. If you are using
syscall hooking with Linux 2.6, the dependency will still exist.
I was able to implement this feature by allowing the filename
resolution to occur within the context of the registered process
(rather than the context of the process accessing the file). This
idea came about because this is how we plan to implement filename
lookups with DazukoFS.
It was not possible to implement this idea with syscall hooking
because of the limited information available to Dazuko on for most
system calls.
Please be aware that although syscall hooking is available, LSM is
still the default and recommended method for using Dazuko with Linux
2.6.
It's been quite a long time since Dazuko's last release. This is due
to several factors:
- There has been a lot of proof-of-concept code being written in the
background. This code may serve as a basis for the new DazukoFS as
well as a completely new Dazuko core. Dazuko's code has grown
unnecessarily complex over the last 5 years. (One coule argue that
it was never very clean.) With the experience gained until now, we
could write a much cleaner and more efficient core. Once I complete
a prototype of the new core, I will introduce it in the next
experimental 3.0 preview. I hope to also include cleaned up and
improved DazukoFS support.
- I have been investigating several alternatives and talking to
people. I have been doing research about writing file systems and
(recently) began investigating FUSE seriously. Unfortunately, the
more I learn, the more I see how much work this stackable filesystem
will be. :-/
- A couple months ago I decided to change jobs. This introduced some
political discussions about the Dazuko project and my role as its
maintainer. Although not yet completely sorted out, I believe that
the direction of the project is not at risk by this.
John Ogness
--
Dazuko Maintainer
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Dazuko-devel] 2.3.4-pre1 posted,
John Ogness <=