Re: Dazuko-devel Digest, Vol 13, Issue 1

----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>
Sent: Friday, March 12, 2004 9:44 AM
Subject: Dazuko-devel Digest, Vol 13, Issue 1


> Send Dazuko-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.nongnu.org/mailman/listinfo/dazuko-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dazuko-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: FreeBSD 5 support (John Ogness)
>    2. 2.0.1-pre1 posted (John Ogness)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 08 Feb 2004 23:37:38 +0100
> From: John Ogness <[email protected]>
> Subject: Re: [Dazuko-devel] FreeBSD 5 support
> To: [email protected]
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Hi,
>
> After posting this message, I realized that all of the events listed as
> having a problem, are those that utilze a sys_generic function. Taking a
> quick look into that function I noticed a problem that was causing
> filename lookups to (gracefully) fail. This has now been fixed.
>
> This means that I will be posting a 2.0.1-pre1 version this week. I was
> hoping that after so many months of testing, the 2.0.0 version would be
> able to last a while before fixes would need to be made. Well, it has
> been 3 days since its release and I already have an important fix for
> FreeBSD. Oh well. :-)
>
> John Ogness
>
>
> John Ogness wrote:
> > Hi,
> >
> > I have merged the 2.0 branch into the head branch in CVS. This should
> > make it easier for people to check out the code (since they do not have
> > to worry about which branch they need to check out).
> >
> > This weekend I sat down and implemented the FreeBSD 5 extension. It
> > wasn't too much work, mainly just changes in structures and function
> > names (and going through the FreeBSD 5 source code).
> >
> > It appears to be working as well as the FreeBSD 4 extension. With
> > FreeBSD there are still some issues that I need to resolve (for both 4
> > and 5). Here is the list:
> >
> > 1. exec/unlink/rmdir cannot resolve relative pathnames
> > 2. exec cannot resolve full pathnames in a chroot environment
> >
> > I need to look at why namei() fails in these situations.
> >
> > I am not going to post an official pre-release with this new extension.
> > If you have FreeBSD 5, you can get the code from anonymous CVS with:
> >
> > env CVS_RSH="ssh" cvs -z3 \
> > -d:ext:[email protected]:/cvsroot/dazuko co dazuko
> >
> > John Ogness
>
> -- 
> Dazuko Maintainer
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 16 Feb 2004 23:24:29 +0100
> From: John Ogness <[email protected]>
> Subject: [Dazuko-devel] 2.0.1-pre1 posted
> To: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Hi,
>
> I have posted the pre-release version 2.0.1-pre1. This version fixes the
> FreeBSD problem resolving local filenames (causing missed events). It
> also has full support for FreeBSD 5. My next target platform will most
> likely be Darwin (MacOS X). However, I first want to look into using a
> stackable filesystem rather than hooking file system calls. Hooking file
> system calls is really ugly and it is the one thing that causes other
> kernel developers to frown upon the Dazuko Project.
>
> This version also integrated a new patch that I developed, which allows
> the ON_OPEN event to be generated when files are created. This event has
> been requested for a long time. Unfortunately this event cannot be
> blocked. This is because of my dependency on kernel functions to resolve
> file names based on existing inodes.
>
> Another issue that has been brought to my attention is the file
> structure of the dazuko tgz. It is disorganized, non-intuitive, and
> ugly. The next pre-release will almost certainly have a completely new
> structure. Something like:
>
> src
> src/lib/c
> src/lib/java
> src/example/c
> src/example/java
> bin
> lib
> modules
>
> The configure script will handle all of this, so that it will still be
> easy to build the Dazuko components. The difference is that it should be
> easier for people to find what they've built. Specifically, the examples
> would be put in the "bin" dir, the interface libs in the "lib" dir, and
> the kernel module in the "modules" dir.
>
> John Ogness
>
> -- 
> Dazuko Maintainer
>
>
>
> ------------------------------
>
> _______________________________________________
> Dazuko-devel mailing list
> [email protected]
> http://mail.nongnu.org/mailman/listinfo/dazuko-devel
>
>
> End of Dazuko-devel Digest, Vol 13, Issue 1
> *******************************************
>