The following files now compile:

sys/compat/opensolaris/kern/opensolaris_kmem.c
sys/compat/opensolaris/kern/opensolaris_kobj.c
sys/compat/opensolaris/kern/opensolaris_kstat.c
sys/compat/opensolaris/kern/opensolaris_misc.c
sys/compat/opensolaris/kern/opensolaris_policy.c
sys/compat/opensolaris/kern/opensolaris_string.c
sys/contrib/opensolaris/common/acl/acl_common.c
sys/contrib/opensolaris/common/avl/avl.c
sys/contrib/opensolaris/common/nvpair/nvpair.c
sys/contrib/opensolaris/common/zfs/zfs_namecheck.c
sys/contrib/opensolaris/common/zfs/zfs_prop.c
sys/contrib/opensolaris/uts/common/fs/zfs/arc.c
sys/contrib/opensolaris/uts/common/fs/zfs/bplist.c
sys/contrib/opensolaris/uts/common/fs/zfs/dbuf.c
sys/contrib/opensolaris/uts/common/fs/zfs/dmu.c
sys/contrib/opensolaris/uts/common/fs/zfs/dmu_object.c
sys/contrib/opensolaris/uts/common/fs/zfs/dmu_objset.c
sys/contrib/opensolaris/uts/common/fs/zfs/dmu_send.c
sys/contrib/opensolaris/uts/common/fs/zfs/dmu_traverse.c
sys/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c
sys/contrib/opensolaris/uts/common/fs/zfs/dmu_zfetch.c
sys/contrib/opensolaris/uts/common/fs/zfs/dnode.c
sys/contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c
sys/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c
sys/contrib/opensolaris/uts/common/fs/zfs/dsl_dir.c
sys/contrib/opensolaris/uts/common/fs/zfs/dsl_pool.c
sys/contrib/opensolaris/uts/common/fs/zfs/dsl_prop.c
sys/contrib/opensolaris/uts/common/fs/zfs/dsl_synctask.c
sys/contrib/opensolaris/uts/common/fs/zfs/fletcher.c
sys/contrib/opensolaris/uts/common/fs/zfs/gzip.c
sys/contrib/opensolaris/uts/common/fs/zfs/lzjb.c
sys/contrib/opensolaris/uts/common/fs/zfs/metaslab.c
sys/contrib/opensolaris/uts/common/fs/zfs/refcount.c
sys/contrib/opensolaris/uts/common/fs/zfs/sha256.c
sys/contrib/opensolaris/uts/common/fs/zfs/spa.c
sys/contrib/opensolaris/uts/common/fs/zfs/spa_config.c
sys/contrib/opensolaris/uts/common/fs/zfs/spa_errlog.c
sys/contrib/opensolaris/uts/common/fs/zfs/spa_history.c
sys/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c
sys/contrib/opensolaris/uts/common/fs/zfs/space_map.c
sys/contrib/opensolaris/uts/common/fs/zfs/txg.c
sys/contrib/opensolaris/uts/common/fs/zfs/uberblock.c
sys/contrib/opensolaris/uts/common/fs/zfs/unique.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev_cache.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev_label.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev_mirror.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev_missing.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev_queue.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c
sys/contrib/opensolaris/uts/common/fs/zfs/vdev_root.c
sys/contrib/opensolaris/uts/common/fs/zfs/zap.c
sys/contrib/opensolaris/uts/common/fs/zfs/zap_leaf.c
sys/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c
sys/contrib/opensolaris/uts/common/fs/zfs/zfs_byteswap.c
sys/contrib/opensolaris/uts/common/fs/zfs/zfs_fm.c
sys/contrib/opensolaris/uts/common/fs/zfs/zil.c
sys/contrib/opensolaris/uts/common/fs/zfs/zio.c
sys/contrib/opensolaris/uts/common/fs/zfs/zio_checksum.c
sys/contrib/opensolaris/uts/common/fs/zfs/zio_compress.c
sys/contrib/opensolaris/uts/common/fs/zfs/zio_inject.c
sys/contrib/opensolaris/uts/common/fs/zfs/zvol.c
sys/contrib/opensolaris/uts/common/zmod/adler32.c
sys/contrib/opensolaris/uts/common/zmod/crc32.c
sys/contrib/opensolaris/uts/common/zmod/deflate.c
sys/contrib/opensolaris/uts/common/zmod/inffast.c
sys/contrib/opensolaris/uts/common/zmod/inflate.c
sys/contrib/opensolaris/uts/common/zmod/inftrees.c
sys/contrib/opensolaris/uts/common/zmod/trees.c
sys/contrib/opensolaris/uts/common/zmod/zmod.c
sys/contrib/opensolaris/uts/common/zmod/zmod_subr.c
sys/contrib/opensolaris/uts/common/zmod/zutil.c
  
Admittedly, there are some pending issues that have been #ifndefed out to get this point. Here is a summary of notable changes that have been made, and issues that still need to be addressed. Let's take a look through the set of patches that will be committed shortly. (These patches have been trimmed manually for legibility, so there should be no expectation for these to work. Use CVS.)

  • Makefile

    diff -b -d -u -r1.1 Makefile.files
    --- contrib/opensolaris/uts/common/Makefile.files	28 Jun 2007 21:51:56 -0000	1.1
    +++ contrib/opensolaris/uts/common/Makefile.files	11 Aug 2007 22:49:02 -0000
     
    +# XXX Edited for ZVOL
      
    -	opensolaris_atomic.o	\
    -	opensolaris_zfs.o	\
    -	opensolaris_zone.o	\
    -	zfs_znode.o		\
    -	zfs_acl.o		\
    -	zfs_ctldir.o		\
    -	zfs_dir.o		\
    -	zfs_ioctl.o		\
    -	zfs_log.o		\
    -	zfs_replay.o		\
    -	zfs_rlock.o		\
    -	zfs_vfsops.o		\
    -	zfs_vnops.o		\
        
    I am not yet concerned with the ZFS filesystem-- merely storage pool volumes.

  • Atomic Ops

    diff -b -d -u -r1.1 atomic.h
    --- compat/opensolaris/sys/atomic.h	28 Jun 2007 21:51:42 -0000	1.1
    +++ compat/opensolaris/sys/atomic.h	11 Aug 2007 22:49:00 -0000
    @@ -1,7 +1,12 @@
    +/*	$NetBSD: atomic.h,v 1.1.2.2 2007/04/13 04:09:43 thorpej Exp $	*/
    +
     /*-
    - * Copyright (c) 2007 Pawel Jakub Dawidek 
    + * Copyright (c) 2007 The NetBSD Foundation, Inc.
      * All rights reserved.
      *
    + * This code is derived from software contributed to The NetBSD Foundation
    + * by Jason R. Thorpe.
    + *
        
    I am using the headers from the netbsd-thorpej-atomic branch. I haven't been able to find the implementation, so I'm guessing it doesn't exist yet. Though the code compiles, we will certainly hit errors when trying to link (if we're not able to determine that sort of thing LKMs, I'll probably configure another Makefile for static compilation.

    retrieving revision 1.1
    diff -b -d -u -r1.1 Makefile
    --- Makefile	30 Jul 2007 15:21:45 -0000	1.1
    +++ Makefile	11 Aug 2007 22:48:59 -0000
    @@ -80,6 +80,9 @@
     
    +# XXX FIXME arc.c needs atomic_add_64()
    +CFLAGS+=-D__HAVE_ATOMIC64_OPS
        
    I don't know what's going to happen if we don't have 64b atomic ops. Arc.c has several calls to atomic_*_64().

  • Kmem Compatibility

    diff -b -d -u -r1.2 opensolaris_kmem.c
    --- compat/opensolaris/kern/opensolaris_kmem.c	30 Jul 2007 15:21:46 -0000	1.2
    +++ compat/opensolaris/kern/opensolaris_kmem.c	11 Aug 2007 22:48:59 -0000
    @@ -112,8 +112,11 @@
     kmem_size(void)
     {
     
    +#ifndef __NETBSD__
     	return ((u_long)vm_kmem_size);
    +#else	/* FIXME */
    +	return 0;
    +#endif
     }
        
    I was hoping tha kmem_map->size would implement kmem_size(), but kmem_used() returns that value. How does one determine the capacity of kmem?

    Kobj Combatibility

    diff -b -u -d -r1.2 opensolaris_kobj.c
    --- opensolaris_kobj.c	30 Jul 2007 15:21:46 -0000	1.2
    +++ opensolaris_kobj.c	14 Aug 2007 03:40:48 -0000
    @@ -65,23 +68,21 @@
     static void *
     kobj_open_file_vnode(const char *file)
     {
    -	struct thread *td = curthread;
    +	struct lwp *l = curlwp;
     	struct nameidata nd;
    -	int error, flags;
    +	int error;
     
    -	if (td->td_proc->p_fd->fd_rdir == NULL)
    -		td->td_proc->p_fd->fd_rdir = rootvnode;
    -	if (td->td_proc->p_fd->fd_cdir == NULL)
    -		td->td_proc->p_fd->fd_cdir = rootvnode;
    +	if (l->l_proc->p_cwdi->cwdi_rdir == NULL)
    +		l->l_proc->p_cwdi->cwdi_rdir = rootvnode;
    +	if (l->l_proc->p_cwdi->cwdi_cdir == NULL)
    +		l->l_proc->p_cwdi->cwdi_cdir = rootvnode;
     
    -	flags = FREAD;
    -	NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, file, td);
    -	error = vn_open_cred(&nd, &flags, 0, td->td_ucred, NULL);
    -	NDFREE(&nd, NDF_ONLY_PNBUF);
    +	NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_SYSSPACE, file, l);
    +	error = _vn_open(&nd, FREAD, 0);
     	if (error != 0)
     		return (NULL);
     	/* We just unlock so we hold a reference. */
    -	VOP_UNLOCK(nd.ni_vp, 0, td);
    +	VOP_UNLOCK(nd.ni_vp, 0);
     	return (nd.ni_vp);
     }
       
    Porting vnode operations is a very large part of this project. While not all vnode-related code will assuredly work at this point, the above code is a good example of the type of changes that have to occur.
    @@ -89,7 +90,11 @@
     kobj_open_file_loader(const char *file)
     {
     
    +#ifndef __NetBSD__
    	return (preload_search_by_name(file));
    +#else	/* FIXME */
    +	return (NULL);
    +#endif
     }
       
    This is a FreeBSDism that shows up only in kobj compatibility. It comes from their <sys/linker.h>
    @@ -156,7 +165,7 @@
     kobj_read_file_vnode(struct _buf *file, char *buf, unsigned size, unsigned off)
     {
     	struct vnode *vp = file->ptr;
    -	struct thread *td = curthread;
    +	struct lwp *l = curlwp;
     	struct uio auio;
     	struct iovec aiov;
     	int error;
    @@ -169,15 +178,19 @@
     
     	auio.uio_iov = &aiov;
     	auio.uio_offset = (off_t)off;
    +#ifndef __NetBSD__
     	auio.uio_segflg = UIO_SYSSPACE;
    +#endif
     	auio.uio_rw = UIO_READ;
     	auio.uio_iovcnt = 1;
     	auio.uio_resid = size;
    +#ifndef __NetBSD__
     	auio.uio_td = td;
    +#endif
     
    -	vn_lock(vp, LK_SHARED | LK_RETRY, td);
    -	error = VOP_READ(vp, &auio, IO_UNIT | IO_SYNC, td->td_ucred);
    -	VOP_UNLOCK(vp, 0, td);
    +	vn_lock(vp, LK_SHARED | LK_RETRY);
    +	error = VOP_READ(vp, &auio, IO_UNIT | IO_SYNC, l->l_cred);
    +	VOP_UNLOCK(vp, 0);
     	return (error != 0 ? -1 : size - auio.uio_resid);
     }
        
    There are also some differences in the members of strcut uio. I have not determined how/if it is necessary to pass this information to VOP_READ another way.

  • Security Policy Compatibility

    diff -b -d -u -r1.1 opensolaris_policy.c
    --- compat/opensolaris/kern/opensolaris_policy.c	28 Jun 2007 21:51:38 -0000	1.1
    +++ compat/opensolaris/kern/opensolaris_policy.c	11 Aug 2007 22:48:59 -0000
    @@ -38,41 +39,59 @@
    +#ifdef __NETBSD__	/* FIXME */
    +# define priv_check_cred(cred, cmd, num)	(0)
    +
    +static int
    +groupmember(gid_t gid, kauth_cred_t cred)
    +{
    +       int error, result;
    +
    +       result = 0;
    +       (void) kauth_cred_ismember_gid(cred, gid, &result);
    +       return (result); 
    +}
    +#endif
    +
        
     int
    -secpolicy_fs_unmount(struct ucred *cred, struct mount *vfsp __unused)
    +secpolicy_fs_unmount(kauth_cred_t cred, struct mount *vfsp)
     {
     
    -	return (priv_check_cred(cred, PRIV_VFS_UNMOUNT, 0));
    +	return (kauth_authorize_system(cred, KAUTH_SYSTEM_MOUNT,
    +	    KAUTH_REQ_SYSTEM_MOUNT_UNMOUNT, vfsp, NULL, NULL));
     }
        
    It was trivial to port the unmount request. The others.. not so much. For now they are all stubbed with priv_check_cred().

  • Vnode

    As I said earlier, porting vnode makes up a large part of this project (and likely, even a larger part in porting the rest of ZFS). Luckily, most of this isn't critical for zpools, so just achieving compilation should be sufficient.

    diff -b -u -d -r1.2 vnode.h
    --- vnode.h	30 Jul 2007 15:21:47 -0000	1.2
    +++ vnode.h	14 Aug 2007 04:18:32 -0000
    @@ -48,11 +48,8 @@
     
     #define	v_count	v_usecount
     
    -static __inline int
    -vn_is_readonly(vnode_t *vp)
    -{
    -	return (vp->v_mount->mnt_flag & MNT_RDONLY);
    -}
    +#define vn_is_readonly(vp)	(vn_writechk((vp)) == ETEXTBSY)
    +
     #define	vn_vfswlock(vp)		(0)
     #define	vn_vfsunlock(vp)	do { } while (0)
     #define	vn_ismntpt(vp)		((vp)->v_type == VDIR && (vp)->v_mountedhere != NULL)
    @@ -141,6 +138,13 @@
     		vap->va_mask |= AT_MODE;
     }
     
    +static __inline int
    +nb_vn_open(struct nameidata *ndp, int filemode, int createmode)
    +{
    +
    +	return (vn_open(ndp, filemode, createmode));
    +}
    +
        
    Before papering over vn_open(), it's copied into a safe namespace for access from compat modules.
     #define	FCREAT	O_CREAT
     #define	FTRUNC	O_TRUNC
     #define	FSYNC	FFSYNC
    @@ -216,16 +225,17 @@
     
     	ASSERT(flag == FSYNC);
     
    -	/* XXX vfslocked = VFS_LOCK_GIANT(vp->v_mount); */
    -	/* FIXME */
        
    We don't have a giant lock, right? Might anything else need to happen here in terms of locks?
    +#ifndef __NetBSD__
     	if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0)
     		goto drop;
    -	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, l);
    +#endif
        
    I see that NetBSD used to have vn_start_write(). I haven't tracked through commit logs yet, but I take its absence to indicate that this step is not necessary any longer.
    +	vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
     	error = VOP_FSYNC(vp, cr, MNT_WAIT, /* FIXME offsets */ 0, 0, l);
    -	VOP_UNLOCK(vp, 0, l);
    +	VOP_UNLOCK(vp, 0);
    +#ifndef __NetBSD__
     	vn_finished_write(mp);
    +#endif
        
    And similarly, above.
    @@ -249,7 +259,11 @@
     
     	ASSERT(seg == UIO_SYSSPACE);
     
    +#ifndef __NetBSD__
     	return (kern_rename(curlwp, from, to, seg));
    +#else	/* FIXME */
    +	return (ENOTSUP);
    +#endif
     }
    @@ -260,7 +274,11 @@
     	ASSERT(seg == UIO_SYSSPACE);
     	ASSERT(dirflag == RMFILE);
     
    +#ifndef __NetBSD__
     	return (kern_unlink(curlwp, fnamep, seg));
    +#else	/* FIXME */
    +	return (ENOTSUP);
    +#endif
     }
     
     #endif	/* _OPENSOLARIS_SYS_VNODE_H_ */
        
    Any pointers on replacements for kern_unlink() and kern_rename()?

  • Zones compatibility

    diff -b -d -u -r1.1 zone.h
    --- compat/opensolaris/sys/zone.h	28 Jun 2007 21:51:52 -0000	1.1
    +++ compat/opensolaris/sys/zone.h	11 Aug 2007 22:49:01 -0000
    @@ -40,22 +38,9 @@
     /*
      * Is process in the global zone?
      */
    -#define	INGLOBALZONE(p)	(!jailed((p)->p_ucred))
    -
    -/*
    - * Attach the given dataset to the given jail.
    - */
    -extern int zone_dataset_attach(struct ucred *, const char *, int);
    -
    -/*
    - * Detach the given dataset to the given jail.
    - */
    -extern int zone_dataset_detach(struct ucred *, const char *, int);
    +#define	INGLOBALZONE(p)	(p != NULL)
     
    -/*
    - * Returns true if the named pool/dataset is visible in the current zone.
    - */
    -extern int zone_dataset_visible(const char *, int *);
    +#define zone_dataset_visible(s, n)	(1)
     
     #else	/* !_KERNEL */
        
    Early on in the project, I tried to rip a lot of the zones stuff out. It still creeps up in a few places, so I implemented the minimal set of stubs above. I may add some more as I start to look at minimizing the size of my diffs.

  • Adaptive Resource Cache

    diff -b -d -u -r1.1 arc.c
    --- contrib/opensolaris/uts/common/fs/zfs/arc.c	28 Jun 2007 21:51:57 -0000	1.1
    +++ contrib/opensolaris/uts/common/fs/zfs/arc.c	11 Aug 2007 22:49:03 -0000
    @@ -148,3 +152,5 @@
    +/*
    + * FIXME These tunables are for performance analysis.
     TUNABLE_ULONG("vfs.zfs.arc_max", &zfs_arc_max);
     TUNABLE_ULONG("vfs.zfs.arc_min", &zfs_arc_min);
     SYSCTL_DECL(_vfs_zfs);
    @@ -159,6 +158,7 @@
         "Maximum ARC size");
     SYSCTL_ULONG(_vfs_zfs, OID_AUTO, arc_min, CTLFLAG_RD, &zfs_arc_min, 0,
         "Minimum ARC size");
    + */
         
    More sysctl FIXMEs...
    @@ -2792,10 +2796,12 @@
     	(void) thread_create(NULL, 0, arc_reclaim_thread, NULL, 0, &p0,
     	    TS_RUN, minclsyspri);
     
    +#ifndef __NETBSD__	/* FIXME */
     #ifdef _KERNEL
     	arc_event_lowmem = EVENTHANDLER_REGISTER(vm_lowmem, arc_lowmem, NULL,
     	    EVENTHANDLER_PRI_FIRST);
     #endif
    +#endif
     
     	arc_dead = FALSE;
        
    FreeBSD uses their EVENTHANDLER framework to monitor a low-watermark in their VM system. To the best that I can tell, this is equivalent to knote(9). However, I have found no uvm-related knotes at this point. Any pointers?

  • dmu_send

    I am replacing the FreeBSD dmu_send.c with the original Solaris version, which compiles with one small modification:

    diff -b -d -u -r1.1 dmu_send.c
    --- onnv/uts/common/fs/zfs/dmu_send.c			08 Jun 2007 15:11:35 -0400
    +++ contrib/opensolaris/uts/common/fs/zfs/dmu_send.c	11 Aug 2007 23:44:13 -0400
    @@ -160,8 +160,10 @@
            void *data = bc->bc_data;
            int err = 0;
     	 
     +#ifndef __NETBSD__     /* FIXME */
             if (issig(JUSTLOOKING) && issig(FORREAL))
                     return (EINTR);
     +#endif
     
              ASSERT(data || bp == NULL);
        
    I do not know if there is an equivalent for this bit of code in NetBSD.

  • Sysctl

    Sysctl(9) is not been fully ported yet. This is one (of many) examples:

    diff -b -d -u -r1.2 spa.c
    --- contrib/opensolaris/uts/common/fs/zfs/spa.c	30 Jul 2007 15:15:32 -0000	1.2
    +++ contrib/opensolaris/uts/common/fs/zfs/spa.c	11 Aug 2007 22:49:09 -0000
    @@ -59,11 +59,13 @@
     #include <sys/fs/zfs.h>
     #include <sys/callb.h>
     #include <sys/sunddi.h>
    +#include <sys/vnode.h>
     
    -/* FIXME */
     int zio_taskq_threads = 0;
    +#ifndef __NETBSD__	/* FIXME */
     SYSCTL_DECL(_vfs_zfs);
     SYSCTL_NODE(_vfs_zfs, OID_AUTO, zio, CTLFLAG_RW, 0, "ZFS ZIO");
     TUNABLE_INT("vfs.zfs.zio.taskq_threads", &zio_taskq_threads);
     SYSCTL_INT(_vfs_zfs_zio, OID_AUTO, taskq_threads, CTLFLAG_RW,
         &zio_taskq_threads, 0, "Number of ZIO threads per ZIO type");
    +#endif
        

    One notable use of sysctl (in the ARC) is the kstat compability code. The kstat compat code is intended to interface with sysctl through the following kstat calls:

    • kstat_create()

      Configures nodes in the sysctl tree in the form:

      	  kstat.<module>.<class>.<name>
      	
      The class sysctlnode is returned in ksp->ks_sysctl_root.
      diff -b -u -d -r1.1 opensolaris_kstat.c
      --- opensolaris_kstat.c	28 Jun 2007 21:51:37 -0000	1.1
      +++ opensolaris_kstat.c	14 Aug 2007 03:40:31 -0000
      @@ -62,6 +75,7 @@
       	 *
       	 *	kstat....
       	 */
      +#ifndef __NetBSD__
       	sysctl_ctx_init(&ksp->ks_sysctl_ctx);
       	root = SYSCTL_ADD_NODE(&ksp->ks_sysctl_ctx,
       	    SYSCTL_STATIC_CHILDREN(_kstat), OID_AUTO, module, CTLFLAG_RW, 0,
      @@ -90,11 +104,41 @@
       		free(ksp, M_KSTAT);
       		return (NULL);
       	}
      +#else	/* FIXME */
      +	root = NULL;
      +	if (sysctl_createv(NULL, 0, NULL, &root, 0, CTLTYPE_NODE, "kstat",
      +	    NULL, NULL, 0, NULL, 0, CTL_KERN, CTL_CREATE, CTL_EOL) != 0) {
      +		printf("%s: Cannot create kstat tree!\n", __func__);
      +		free(ksp, M_KSTAT);
      +		return NULL;
      +	}
      +	if (sysctl_createv(NULL, 0, &root, &root, 0, CTLTYPE_NODE, module,
      +	    NULL, NULL, 0, NULL, 0, CTL_CREATE, CTL_EOL) != 0) {
      +		printf("%s: Cannot create kstat.%s tree!\n", __func__, module);
      +		free(ksp, M_KSTAT);
      +		return NULL;
      +	}
      +	if (sysctl_createv(NULL, 0, &root, &root, 0, CTLTYPE_NODE, class,
      +	    NULL, NULL, 0, NULL, 0, CTL_CREATE, CTL_EOL) != 0) {
      +		printf("%s: Cannot create kstat.%s.%s tree!\n", __func__,
      +		    module, class);
      +		free(ksp, M_KSTAT);
      +		return NULL;
      +	}
      +	if (sysctl_createv(NULL, 0, &root, &root, 0, CTLTYPE_NODE, name,
      +	    NULL, NULL, 0, NULL, 0, CTL_CREATE, CTL_EOL) != 0) {
      +		printf("%s: Cannot create kstat.%s.%s.%s tree!\n", __func__,
      +		    module, class, name);
      +		free(ksp, M_KSTAT);
      +		return NULL;
      +	}
      +#endif
       	ksp->ks_sysctl_root = root;
       
       	return (ksp);
       }
       
      +#ifndef __NetBSD__
       static int
       kstat_sysctl(SYSCTL_HANDLER_ARGS)
       {
      @@ -104,6 +148,29 @@
       	val = ksent->value.ui64;
       	return sysctl_handle_quad(oidp, &val, 0, req);
       }
      +#else
      +static int
      +kstat_sysctl(SYSCTLFN_ARGS)
      +{
      +	struct sysctlnode	 node;
      +	uint64_t		 val;
      +	kstat_named_t		*ksent;
      +	int			 error;
      +
      +	node = *rnode;
      +	ksent = newp;
      +
      +	node.sysctl_data = &val;
      +
      +	error = sysctl_lookup(SYSCTLFN_CALL(&node));
      +	if (error || newp == NULL)
      +		return (error);
      +
      +	val = ksent->value.ui64;
      +
      +	return (0);
      +}
      +#endif
                

    • kstat_install()

      Add a knode_named_t into sysctl as *newp. (via kstat_sysctl() (above). The sysctl helper needs to be looked at to determine whether it will work at all as expected.

       void
       kstat_install(kstat_t *ksp)
      @@ -113,12 +180,18 @@
       
       	ksent = ksp->ks_data;
       	for (i = 0; i < ksp->ks_ndata; i++, ksent++) {
      -		KASSERT(ksent->data_type == KSTAT_DATA_UINT64,
      -		    ("data_type=%d", ksent->data_type));
      +		KASSERT(ksent->data_type == KSTAT_DATA_UINT64);
      +#ifndef __NetBSD__
       		SYSCTL_ADD_PROC(&ksp->ks_sysctl_ctx,
       		    SYSCTL_CHILDREN(ksp->ks_sysctl_root), OID_AUTO, ksent->name,
       		    CTLTYPE_QUAD | CTLFLAG_RD, ksent, sizeof(*ksent),
       		    kstat_sysctl, "QU", "");
      +#else
      +		sysctl_createv(NULL, 0, &ksp->ks_sysctl_root, NULL,
      +		    CTLFLAG_READWRITE, CTLTYPE_QUAD,
      +		    ksent->name, NULL, kstat_sysctl, 0, ksent, sizeof(*ksent),
      +		    CTL_CREATE, CTL_EOL);
      +#endif
       	}
       }
              

    • kstat_delete()

      Free the kstat data. I don't know if we should teardown parts of the sysctl tree too.

      @@ -126,6 +199,8 @@
       kstat_delete(kstat_t *ksp)
       {
       
      +#ifndef __NetBSD__
       	sysctl_ctx_free(&ksp->ks_sysctl_ctx);
      +#endif
       	free(ksp, M_KSTAT);
       }
              

    Also, I don't know if a SYSCTL_SETUP function is necessary-- I don't believe it is.

  • mutex

    diff -b -u -d -r1.3 mutex.h
    --- compat/opensolaris/sys/mutex.h      30 Jul 2007 15:21:46 -0000      1.3
    +++ compat/opensolaris/sys/mutex.h      12 Aug 2007 06:16:41 -0000
    @@ -53,6 +55,8 @@
     #define mutex_init(mtx, desc, type, arg)                               \
            zfs_mutex_init((mtx), (desc), (type), (arg))
     
    +#define mutex_owner(mtx)       ((struct lwp *)(mtx)->mtx_owner)
    +
     #endif /* _KERNEL */
     
     #endif /* _OPENSOLARIS_SYS_MUTEX_H_ */
        
    I was unsure how to mimick mutex_owner(). I finally found the following in %lt;sys/mutex%gt;:
    (isla)$ nl -ba /usr/src/sys/sys/mutex.h | sed -n 54,60p
        54   *      struct mutex
        55   *              The actual mutex structure.  This structure is mostly
        56   *              opaque to machine-independent code; most access are done
        57   *              through macros.  However, machine-independent code must
        58   *              be able to access the following members:
        59   *
        60   *              uintptr_t               mtx_owner
        ..   .              ...			...
        

    However, we have to define __MUTEX_PRIVATE to get this macro (in sys/arch/x86/include/mutex.h by doing the following:

    @@ -34,7 +34,9 @@
     
     #ifdef _KERNEL
     
    +#define __MUTEX_PRIVATE                /* We need mtx_owner */
     #include_next 
    +
     #include  <sys/param.h>
     /* XXX #include <sys/proc.h> */
     #include  <sys/lock.h>
        

  • Adaptive Replacement Cache

    diff -b -d -u -r1.1 arc.h
    --- contrib/opensolaris/uts/common/fs/zfs/sys/arc.h	28 Jun 2007 21:52:19 -0000	1.1
    +++ contrib/opensolaris/uts/common/fs/zfs/sys/arc.h	11 Aug 2007 22:49:15 -0000
    @@ -39,0 +40,4 @@
    +#ifdef __NETBSD__	/* XXX Namespace clash with buf.h */
    +# undef b_data
    +# undef b_private
    +#endif
        
    A nasty, annoying namespace clash with <sys/buf.h> forces me to undefine the above two macros (which are otherwise used to access data and private elements within a union). I hope this doesn't cause a problem.

  • Asynchronous Read/Write calls

    --- contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h	28 Jun 2007 21:52:28 -0000	1.1
    +++ contrib/opensolaris/uts/common/fs/zfs/sys/zvol.h	11 Aug 2007 22:49:16 -0000
    @@ -51,8 +51,10 @@
     extern int zvol_strategy(buf_t *bp);
     extern int zvol_read(dev_t dev, uio_t *uiop, cred_t *cr);
     extern int zvol_write(dev_t dev, uio_t *uiop, cred_t *cr);
    +# ifndef __NetBSD__
     extern int zvol_aread(dev_t dev, struct aio_req *aio, cred_t *cr);
     extern int zvol_awrite(dev_t dev, struct aio_req *aio, cred_t *cr);
    +# endif
     #endif
     extern int zvol_ioctl(dev_t dev, int cmd, intptr_t arg, int flag, cred_t *cr,
         int *rvalp);
        
    Async-Read/Write is not implemented.

  • Prototypes and Function Pointers

    While all of the Solaris code is generally lucid, <bsd.kmod.mk> uses pretty strict warning flags (e.g. -Wstrict-prototypes -Wmissing-prototypes). Furthermore, the Solaris headers qualify prototypes with extern. I have added all missing prototypes to the beginning of each C file. This can easily be reversed at some point, but it made my life a lot easier...

    Similarly, this strictness affects function pointer declaration. Therefore, the types of (missing) arguments were specified as in the followng example from sys/contrib/opensolaris/uts/common/fs/zfs/sys/zil.h:236:

        < typedef int zil_replay_func_t();
        > typedef int zil_replay_func_t(void*,void*,boolean_t);
        

  • Remaining compile errors

    Of course, there are still some compile errors left in sys/contrib/opensolaris/uts/common/os/. The one I'm currently at follows:

    #   compile  sys/taskq.o
    cc -O2 -D_SOLARIS_C_SOURCE -D__HAVE_ATOMIC64_OPS
    -I~/src/zfs/src/sys/compat/opensolaris
    -I~/src/zfs/src/sys/contrib/opensolaris/uts/common/fs/zfs
    -I~/src/zfs/src/sys/contrib/opensolaris/uts/common/zmod
    -I~/src/zfs/src/sys/contrib/opensolaris/uts/common
    -I~/src/zfs/src/sys/contrib/opensolaris/common/zfs
    -I~/src/zfs/src/sys/contrib/opensolaris/common
    -I~/src/zfs/src/sys/../include -I~/src/zfs/src/sys
    -ffreestanding  -fno-strict-aliasing -Wno-pointer-sign -Wall -Wstrict-prototypes
    -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wall
    -Wno-unknown-pragmas -Wno-missing-braces -Wno-parentheses -Wno-uninitialized
    -Wno-unused -Wno-switch -Werror   -nostdinc -I. -I~/src/zfs/src/sys
    -isystem /usr/src/sys -isystem /usr/src/sys/arch -isystem
    /usr/src/sys/../common/include -D_KERNEL -D_LKM  -c
    ~/src/zfs/src/sys/contrib/opensolaris/uts/common/os/taskq.c
    In file included from /usr/src/sys/sys/device.h:80,
                     from ~/src/zfs/src/sys/x86/pic.h:6,
                     from ~/src/zfs/src/sys/machine/pic.h:3,
                     from ~/src/zfs/src/sys/x86/intr.h:45,
                     from ~/src/zfs/src/sys/machine/intr.h:3,
                     from /usr/src/sys/sys/mutex.h:187,
                     from ~/src/zfs/src/sys/compat/opensolaris/sys/mutex.h:38,
                     from ~/src/zfs/src/sys/compat/opensolaris/sys/taskq_impl.h:32,
                     from ~/src/zfs/src/sys/contrib/opensolaris/uts/common/os/taskq.c:374:
    /usr/src/sys/sys/evcnt.h:85: error: expected specifier-qualifier-list before 'uint64_t'
        
    Otherwise, in this directory, it's the pretty standard fare of prototype warnings and #ifndefing around SYSINIT(..).

    And outside of these problems, we're at least compiling ;). Next comes the fun task of (trying to) link zfs into the kernel, which almost has to be done statically, as I understand it, in order to get reasonable information.

2007/08/14 15:56

Most of zvol & vdev_disk is complete (though untested). Here's a summary of notable aspects and pending issues related to these two interfaces:

Pseudo disk structure

  • The ZVOL top-half presents a volume through a device node.
  • Calls go through the ZVOL device into the Intent Log (ZIL), through the I/O Pipeline (ZIO), where much of the ZFS magic occurs,
  • And then eventually the Virtual Devices (vdevs) interact with the underlying disk drivers.

In order to configure the pseudo disk, we do the following:

/*
 * Configure pseudo-disk interface
 */
zv->zv_dk.dk_name = zv->zv_name;
zv->zv_dk.dk_driver = &zvoldkdriver;
pseudo_disk_init(&zv->zv_dk);
zv->zv_flags = DKF_INITED;

/*
 * XXX Is there a need to set a geometry.  It is very likely possible
 * that zv_volsize can handle everything.
 */

/* Attach ZVOL */
pseudo_disk_attach(&zv->zv_dk);

dkwedge_discover(&zv->zv_dk);

At one point I was using the dk_softc structure out of sys/dev/dkvar.h, which, you may notice, has many of the same fields that are in the zvol's softc:

struct zvol_softc {
	struct device	 zv_device;     	/* device softc for driver(9) */
	char		 zv_name[MAXPATHLEN];	/* pool/dd name */
	uint64_t	 zv_volsize;		/* amount of space we advertise */
	uint64_t	 zv_volblocksize;	/* volume block size */

Note that there are sufficiently large types to hold these values. dk_softc.sc_size is only a (4 byte) size_t.

	minor_t		 zv_minor;      /* minor number */
	uint8_t		 zv_min_bs;     /* minimum addressable block shift */
	uint8_t		 zv_readonly;   /* hard readonly; like write-protect */
	objset_t	*zv_objset;     /* objset handle */
	uint32_t	 zv_mode;       /* DS_MODE_* flags at open time */
	uint32_t	 zv_total_opens; /* total open count */
	zilog_t		*zv_zilog;      /* ZIL handle */
	uint64_t	 zv_txg_assign; /* txg to assign during ZIL replay */
	znode_t		 zv_znode;      /* for range locking */
	struct disk	 zv_dk;         /* disk interface */
	uint32_t	 zv_flags;      /* DKF_* state flags */
};

IOCTLs

  • case DKIOCFLUSHWRITECACHE:
    case DIOCCACHESYNC:

    I've think I've got this one figured out, actually.

    I was forewarned about the cache-flushing ioctl being important to proper ZFS behavior. Solaris's DKIOCFLUSHWRITECACHE is, I believe, equivalent to NetBSD's DIOCCACHESYNC (once the disk's write cache has been enabled with (DIOCSCACHE, DKCACHE_WRITE)). In the underlying vdevs, VOP_IOCTL(DIOCCACHESYNC) is performed on the backing device node's vnode.

    The vnode, in this case (or, at this point?), is that yielded from a lookup(9) on the device node as specified to zpool(1).

  • case DIOCAWEDGE:
    case DIOCDWEDGE:
    case DIOCLWEDGES:

    These were trivial to import from pre-existing pseudo-disk drivers.

  • case DIOCGDINFO:
    case DIOCWDINFO:
    case DIOCSDINFO:
    case DIOCGPART:
    case DIOCWLABEL:
    case DIOCGDEFLABEL:

    These have not been absolutely trivial to import. Can these IOCTLs be left unsupported? As I understand it, we could simply require GPT labels to be written for ZVOL storage.

Proplib

gpt(8) uses drvctl to get sector and media size, so we need to update the prop_dictionary in the zvol_softc with accurate information. sys/kern/kern_drvctl.c uses the dv_properties dictionary in struct device. However, ld(4) uses the dk_info in struct disk. I haven't resolved what needs to be done here. Either way, I gather that (de)referencing will have to occur during disk attachment and detachment.

Disk IDs

Also, Solaris and FreeBSD are able to keep track of a unique disk identifications, so that when a disk is reattached, e.g. on a different controller, it can be detected and correctly added to the proper zpool.

Stay tuned for the next half of this status update...

2007/08/09 22:48
Since dynamic device node creation is not currently possible (not easily, at least) in NetBSD, zvol-attaching and mounting will be handled much differently than in other implementations, at least within the context of the summer.

ZVOLs are "created" through zvol_create_minor(name, dev) (by ioctls on /dev/zfs, and therefore zfs_ioctl.c). NetBSD's implementations uses namei(9) to find the vnode of the device node of the given volume, and then the minor number is determined with VOP_GETATTR(9).

Actually, it comes as an afterthought that device node creation may be possible with VOP_MKNOD(9) (basically, copying the mknod(2) code). Doing this is clearly not the first (or next) step, but it may be a workable interim solution (a la compat layer?).

Each ZVOL's soft state (struct zvol_softc, which is based on Solaris's struct zvol_state) is stored in an array, zvol_softcs, of pointers. Individual softcs are accessed and manipulated, by minor number, through zvol_softc_get(minor), zvol_softc_zalloc(minor), zvol_softc_free(minor). This behaviour is largely based on that of cgd(4).

However, I have to say that I have not been able to fully make top and bottom of how a disk driver like this should work. Though, for instance, cgd and vnd both provide virtual disk drivers through pre-configured device nodes, they accomplish this (seemingly) differently. To wit, cgd maintains an array of softcs, as I currently do in zvol, and uses neither CFATTACH nor CFDRIVER_DECL (as is the same for ccd). The vnd driver does, and it accesses each zvol with driver_lookup(). Having to pick one approach, I'll go with c.?d(4)'s (because I've already implemented that). However, vnd is the only one loadable as an LKM.

A lot of other things have happened since I've last posted, which has been a long time. Rather than try to recap everything at once, I'd prefer to focus on moving forward.

2007/07/20 12:03
Thanks to Zafer, I've been keeping olix0r.net despiste my incredible inability to reclaim (legitimate) internet access at my new residence. He's gone out of his way to give me CGI functionality to run Blosxom.

Aside from that, life has been exciting. I took a "vacation" this week to get some Real Work done, but that is still an uphill battle. (Updates in the near term).

Also, John From Cincinatti might be the best television show ever.

2007/06/29 22:25
I'm happy to say that I have read the previously-mentioned ;login: article.

In summary, I think that Pawel and Marshall do a good job. Their overview of ZFS should be more than sufficient for anyone that reads ;login: but has managed to keep bunkered under a rock for long enough not to have seen the brochures.

On to the main course, though-- a summary of Pawel's work porting ZFS to FreeBSD. Reading it, I was surprised at how much I knew already. That said, I am surprised at how I did not put the clues together into a clearer plan for this summer's project. Specifically, I've known about (and read.. and discussed) FreeBSD's OpenSolaris compat layer. What I somehow did not correlate, though, is that most of the work I have slated for this summer will be limited to this layer. I anticipate that it will take me some time to grok the individual interfaces properly, but this is where my mentors are really likely to lend a hand.

So today-- optimism.

I could try to blame other factors for clouding my mind, but I think ultimately my project's "negative-slack" (a former professor's euphemism for schedule-crunch) is due to a lack of intimacy with the code, an aversion to premature assumptions, and, moreover, fear of failure. Completing my initial development plan, and getting some code committed will, I'm sure, give me some much-needed confidence and momentum. It's always interesting to me, though not surprising at all, how human factors manage to bleed into technical work.

2007/06/13 07:48
Today I did a bit of catching up on zfs-discuss@opensolaris (it's quite a high-volume list, and many of the issues discussed therein are not as useful as-- say-- tech-kern@netbsd). Pawel Dawidek and Marshall McKusick wrote an article on FreeBSD's ZFS implementation for the June 07 issue of ;login:. Unfortunately, I'm not currently a Usenix member (professional affiliation? what's that?); but a friend passed the article along upon my request. This has encouraged me, though, to make sure I get membership in the near future.

It's not quite the blueprint I hoped for, but it will certainly be useful nonetheless. I'll print it out tomorrow morning to read over lunch.

Only having skimmed the article, the section on Zones & Jails caught my eye. I had noticed that zone implementation simply wrapped FreeBSD's jail interface when browsing the compatibility layer, but forgot about / disregarded it. I understand that there is no analog in NetBSD, but at this point I am unsure whether it is best to completely axe code, or if it's cleaner to null-stub the zones interface.

It will be better to discuss all of this after I read the article more fully.

2007/06/11 00:08
I considered simply posting the lyrics to the Pixies song to summarize where I am at the moment, but I decided to be a little more descriptive...

I've been scratching at the ZFS flows I posted a few days ago. I realized that I made a mistake by diving right into reading the Storage Pool Layer code. Doing so was mostly useless, as I am without context with regard to the specific functionality implemented therein. Rather, it makes much more sense to start reading at the start, e.g. in userland.

I've found no real documentation on what libzpool is, exactly. It doesn't have a header file, though it exists as its own subdir in lib/libzpool. I'm not even sure where it's linked from. At the moment, I'm assuming it's really a part of libzfs. In order to determine what functions are provided by libzpool, I did the following:

( cd ~/src/freebsd/contrib/opensolaris/ ; \
for c in lib/libzpool/common/*.c
do
	# For each c file in libzpool
	# - Delete all static functions
	# - Print each remaining function name preceded by the line number
	# - Then, to format the output
	#   - Collapse the line number and function name
	#   - Prepend the filename
	# This form will be easy to merge into cflow output.
	sed -e '/^static/,/^}/d' \
			-n -e '/^\([^(  ]\{1,\}\)(.*$/{=;s//\1/p;}' ${c} | \
		sed -e '/[0-9]\{1,\}/N' \
			-e 's/\n/:/' \
			-e "s,^,${c}:,"
done )
I'm really, really frustrated at the moment. I've got to get to get my head around these things, yet it continually seems that I'm fumbling around with half a clue. Plus, lacking feedback, I'm unsure whether my approach is completely off-base or not. If I can bridge the mental gap between userland and device management, I think I'll be able to get somewhere. Let's make that a reasonable goal for this weekend.
2007/06/09 10:11
I was happy to find that genunix has onnv sources available through subversion, which I already have installed on most of the systems I use regularly. However, I missed the fact that this repository is in no way up-to-date. I've wasted at least a few hours this week exploring the apparent differences between FreeBSD's contrib/opensolaris/cmd/zpool and the (subversion) onnv sources.

Before posting on this, though, I at least did the due diligence to investigate these discrepencies more fully. After installing devel/mercurial and fetching the real current onnv sources, I see that the diffs are much more useful and obvious than they were previously.

Sigh-- a bumpy start, indeed. I'm almost finished moving. I'm very excited to dive into this and get to nuts & bolts & code. Though, I'm still a little bit disoriented (in more ways than SoC, certainly), I am working hard to get my bearings and make some quantifiable progress.

2007/06/05 23:04
Google's Summer of Code has been live since the beginning of this week. As I haven't posted in a while, I've got a few things to update on:

Test System

I've gathered some (mostly scrap) hardware to run netbsd-current and SolarisExpress b62 (hereafter, "onnv"). It has 2x250G SATA disks and a ~40G IDE disk, which should give me some flexibility to test several zpool configurations side-by-side.

I hit my first obstacle when trying to install onnv. I had installed NetBSD (2.1, I think; -current has already been built on my laptop, but hasn't been installed yet) from CD without issue. However, onnv would not install. I have the luxury of having a very similar configuration on my desk, where the onnv disk booted into the installer. By swapping the DVD drives (note: they are the same model of LG from ~3-4 years ago), things worked out.

Then, I ran into a small headache trying to get NetBSD to boot out of onnv's Grub setup. Even using chainloader +1, NetBSD's bootloader would hang after (seemingly) finding the kernel. I settled on using NetBSD's boot selector, which loads Grub for Solaris if the appropriate option is selected.

Still, I'm having trouble getting Networking up under onnv; and, no, it's not simply a matter of plumbing (I think). I can find no indication of what driver should be used (it's an ex0 in NetBSD). I've run dladm show-link and show-dev, but each show nothing. A little infuriating. I think last night I dreamt that I went in today and it just worked. Let's hope that happens.

More printouts than you can shake a fish at

I've got a nice fat binder now with, afaict, all of the onnv ZFS sources, as well as the FreeBSD compatibility layers. This has been nice to have to do some studying outdoors, when my laptop's battery dies, etc.

cflow(1)

I started writing some sed scripts to determine what interfaces are used by certain portions of ZFS code, and found this increasingly deficient. I then found devel/cflow in pkgsrc (I think with grep -Ri graph devel/*/DESCR). While cflow2vcg dumped core every time I ran it, the textual output is sufficient.

I've been generating call-graphs for the Storage Pool Layer, but I want to refine them a little more before posting them or getting into more detail about my findings. This is what I've done to generate call-graphs so far (posted here primarily for my own reference):

#!/bin/ksh

SRCPREFIX=${HOME}/src/freebsd
CFLOW_OPTIONS="--format=posix --omit-arguments ${CFLOW_OPTIONS}"

cd ${SRCPREFIX}/sys/contrib/opensolaris/uts/common/fs/zfs

cflow  ${CFLOW_OPTIONS} \
        -DFREEBSD_NAMECACHE -D_SOLARIS_C_SOURCE \
        -I../../../../../sys/compat/opensolaris \
        -I../../../../../sys/contrib/opensolaris/uts/common/fs/zfs \
        -I../../../../../sys/contrib/opensolaris/uts/common/zmod \
        -I../../../../../sys/contrib/opensolaris/uts/common \
        -I../../../../../sys/sys \
        -I../../../../../sys/contrib/opensolaris/common/zfs \
        -I../../../../../sys/contrib/opensolaris/common \
        -I../../../../../../include \
        @(arc*|spa*|txg|spa*|vdev*).c 2>/dev/null
Still a lot of puzzlement and wonder; but I've made some definite progress.

Does anyone have any thoughts on how useful either of these [1, 2] Solaris Internals books will be to the project? I thought some of my SoC startup money could go to either/both of these. Any other suggested investments? Let me know at <ogould@...>.

2007/06/02 00:04
I've added a little to the cflow-generating script I posted yesterday. I've generated flows for the Storage Pool Layer and the various zpool(1) commands.

I've yet to make it through libzpool at this point, as I've still got to determine the entry points from the zpool flows.

2007/06/01 09:46
I'm moving this weekend. I'm moving, actually, to an apartment I've lived in previously-- which is pretty funny. It should be a much better situation this time around, though.

olix0r.net may be down for some period of time between now and the end of next week, but I'm going to try to keep the downtime minimal. Let me again plug Speakeasy for having some great customer service. They'll keep both connections up until I'm done moving; or at least that's what I understand to be the agreement.

This whole ordeal will deminish my ability to dive immediately into SoC work, though I am going to try to get a good solid crack at an initial development plan for early next week.

The song Like Spinning Plates comes to mind.

2007/06/01 00:17
Last weekend (May 25-29) olix0r.net was down due to a power outage in my apartment. Meanwhile, I was not in the area this weekend and couldn't fix it until after work on Tuesday. Such is life.
2007/05/31 08:36
If, for instance, you have a file with the contents:
FOO
BAR
FOO
$ tail -f file | grep -m2 FOO
prints FOO twice but never returns. Whereas
$ tail -f file | grep -m2 -e FOO -e BAR
will exit.

This is because (from the grep(1) manual):

	grep ensures that the standard input is positioned to just
	just after  the  last matching line before exiting, regardless of
	the presence of trailing context lines.

This bit me as I was trying to scan xscreensaver-command -watch for an unblanking event. However, because no events followed the UNBLANK immediately, grep didn't return and my script would not continue. I therefore rely on the LOCK event that (hopefully) preceeds the UNBLANK. It's not a big deal if this fails; I'll have to unlock my ssh-agent manually...

2007/05/25 12:46
Not specifically about ZFS, but while trying to install OpenSolaris on a test machine, I get an annoying grub error.

I am really hoping that a new DVD is all that is needed to resolve this...

2007/05/23 15:24
I've printed out several hundred pages of Solaris sources; and I've been trying to correlate interfaces and get my head around the first few steps of the project. At the end of the day, though, I am tired, confused, and a bit intimidated-- generally frustrated. Se la vie.

I can't quite determine how the VDEV disk interface is going to work. I looked at FreeBSD's code, and they have vdev_disk.c in their tree unmodified (though, superceded by vdev_geom*). However, this file does #include <sys/sunldi.h>, though I am unable to find this defined anywhere in FreeBSD's tree. This is really no biggy, but is the end of a tangent on Sun's LDI and DDI interfaces. I'm not quite sure whether NetBSD's disk(9) is going to fit in here, or some other driver(9).

I'm sure I can get past this in the next few days, I just feel a bit overwhelmed at the end of the day in the middle of a crazy week. Hopefully this weekend I'll be able to take a step back, read through some code, and formulate some questions.

However, I did manage to read through a good bit of Cranor's & Parulkar's The UVM Virtual Memory System today, which was certainly enlightening. Maybe my brain is just a little too full for one day.

2007/05/17 21:46
FreeBSD's sys/compat/opensolaris provides several interface ports. Namely:
  • kern/opensolaris_kmem.c
  • kern/opensolaris_kobj.c
  • kern/opensolaris_kstat.c
  • kern/opensolaris_misc.c
  • kern/opensolaris_policy.c kern/opensolaris_string.c
  • kern/opensolaris_vfs.c
  • kern/opensolaris_zone.c

These interfaces use (at least) vm(9) and mutex(9) and will need to be ported. Perhaps it's time for me to re-read some parts of section 9...

2007/05/17 21:37
This weekend I started reading through the VDEV code. I'm surprised-- and quite pleased-- with how clearly written everything is unlike other code [cough kqemu cough] I've had to read recently. I'm not claiming to have the whole thing under my belt at this point, though I am a bit more confident and comfortable with the task ahead.

At the moment, I have to determine:

  • how NetBSD's disk(9) works; especially as compared to Solaris's sys/sunldi.h, sys/sunddi.h, & sys/dkio.h.
  • whether we should replace vdev_disk.@(c|h) with the relevant NetBSD stuff, or whether there should be a new VDEV type (say-- vdev_nbdisk.*). Though, I can't see of what use Sun's interfaces will be to us.
  • how NetBSD's uvm(9) works and if it is related in any way to Solaris's sys/space_map.h. (By the way-- the uvm(9) portions of the NetBSD Internals Guide is really lacking).
  • the nature of various other Solaris interfaces I haven't yet read:
    $ find src/onnv -type f -name vdev\* | \
    	xargs sed -ne 's/^#include <\([^>]*\)>$/\1/p' | sort | uniq
    

Some of this will certainly be made easier by installing my development system with SolarisExpress.

2007/05/07 00:35
I was just about to post a minor tirade against "OpenSolaris and their corporate daddy" for, allegedly, not being Open Source enough. I mean, this is a blog, right? So why should I be expected to research before I go blabbing about how stupid I perceive something to be. Luckily, I did some more research...

To my sweet chagrin, I found that there are plenty of places to track OpenSolaris from. And, while I'm not sure that I'll be using mercurial, I have a few alternatives (like svn).

What I mean to say is: "Way to go OpenSolaris!"

2007/05/02 08:59

Wow!

I have made an incredible amount of progress on KQEMU for NetBSD in the past two days. I wrote a small prototypical device LKM to test, and everything else has fallen into place. Lots of stupid errors were vetted this way.

As I started testing compilation today, I was a little distraught to find

  1. The Lunix-binary kqemu-mod-i386.o had, at some point, been deleted from my working source tree.
  2. kqemu-1.3.0pre9.tar.gz (the version I was developing against) is no longer available for download anywhere that I can find.
  3. kqemu-1.3.0pre11 was failing to build natively on NetBSD (with errors regarding inline assemly & registers.

But, (3) was very easily resolved by trying to build on my -current machine instead of NetBSD-2.1.

At this point I have some apparently minor uvm(9) stuff to clean up; and then it's on to testing ;)

2007/04/21 00:47

This is the first time (in the <~1 year I've had Speakeasy) that I have had a network outage. This therefore the first time that I've been stuck on the phone (well, on hold listening to the Carpenters-- and worse) for the first 15 minutes (and counting) of my day. I much prefer their online support... which doesn't really do me much good right now.

Well- there is, apparently, a Central Office problem. It should be up within the hour

We will see.

2007/04/18 08:49

Today saw a signficant CSS revamp to the bitbucket. I like it; but, I guess that's the point.

2007/04/15 01:58

I had been keeping some half-notes on porting KQEMU on my work wesite, but I don't really see that site staying in tact too much longer in its current form. Now that olix0r.net exists, it seems better to keep all of my notes on development in one place.

The following is generally a recap of the work done between 2007/01/10 and 2007/02/07.

  • Reformat kqemu-freebsd.c (rev 1.6) while trying to get a feel for the work needed to be done
  • Translations from FreeBSD interfaces:
    • module(9) -> lkm(9)
    • vm(9) -> uvm(9)
    • scheduler(9) -> scheduler(9)
    • proc(9)/thread(9) -> lwp(9)

Since then, I have been reading (albeit, sporadically) both BSDs' bpf(4) implementations in order to compare the way in which devices are cloned. I've grokked most of it, but there were a seemingly minor difference that were nagging me, which I have since chalked up to bpf(4) implementation differences (rather than API differences).

This evening, I sat down and tried to finish the rest of the KQEMU port. At this point, it's not quite compiling, but I believe all of the interfaces have been translated appropriately. There are several bizarre compile (#include!) errors that I have to mitigate before I can start testing KQEMU.

Now that I look back, it's surprising how little work I had remaining. It was really all about getting throught the bpf(4) code. Really, what I had to do was use the file(9) interface to clone the KQEMU file pointer. This is implemented with a list (from QUEUE(3)) of KQEMU instances.

Tired- but pleased ;)

2007/04/14 22:04

The project was accepted! Here's to a good summer.

2007/04/12 07:48

If you haven't listened to Hello Everything a few hundred times since October, I seriously suggest reevaluating your life.

But, that's just my suggestion..

Edited to add:
What I have mistakenly been calling the Welcome to Europe EP is actually titled Vacuum Tracks. Whatever you call it, it is 4(?) bonus tracks and it comes with select releases of the album. And it too is great.

Tom Jenkinson, thanks.

2007/04/03 22:51

This morning I applied for a Summer of Code project. My proposal follows:

 0 Background
 ============

Sun Microsystem's Zettabyte Filesystem (ZFS), since Nov 2005, has proven to be a
major breakthrough in filesystem technology, supporting features such as disk
pools, snapshots, "unlimited" scalability, and various other performance
improvements over prior art.  Such advancements will make ZFS a major force in
industry in coming years.

A BSD-licensed implementation of ZFS is utterly impractical within the
constraints of Google's Summer of Code (SoC).  However, porting the CDDL'd ZFS
implementation present in OpenSolaris is feasible.  In particular, Pawel Jakub
Dawidek has been able to port a significant portion [1] of ZFS to FreeBSD.  His
work provides a good basis for porting ZFS to NetBSD.

Furthermore, OpenSolaris has published a high-level roadmap [3] for porting ZFS
to other platforms.  This outlines a path for success, which I shall follow.


 1 Objectives
 ============

While Pawel's work provides a valuable starting point for much of my work,
numerous FreeBSD interfaces differ from those in NetBSD, including the virtual
memory (vm(9)/uvm(9)), scheduler(9), driver(9), and file system (vfs(9)) kernel
interfaces.  However, most userland tools require a minimal amount of work to
bring into NetBSD.

The primary objectives of this project are:
 - A functional zpool implementation
 - Documentation and plan for future development

Secondary objectives include:
 - /dev/zfs
 - libzfs
 - ZVOL

 1.1 zpool and testing functionality
 -----------------------------------

Sun's storage pool abstraction, zpool, offers significant advantages over
classical logical volume interfaces such as NetBSD's ld(4).  Porting this
component is the first and foremost objective of this project.  It comprises
roughly 80% of the kernel-land code necessary for a functional ZFS
implementation.

Unfortunately, Pawel's port of zpool relies on FreeBSD's geom(4) interface,
which is not present in NetBSD, for virtual device (VDEV) functionality.  While
NetBSD's VDEV implementation will be fairly straightforward compared to
FreeBSD's, it also requires a significant portion of newly-written code.

The ZFS I/O Pipeline (ZIO) and Adaptive Replacement Cache (ARC) require work
with NetBSD's virtual memory and mutex interfaces.

The ztest, and therefore zdb, userland components will enable me to accurately
test throughout the remainder of the project.  

 1.2 Userland management tools
 -----------------------------

ZFS's userland management tools, zpool(1) and zfs(1), rely on the /dev/zfs
device.  The kernel device will differ from prior implementations, however the
userland tools should not.

 1.3 ZFS Emulated Volume
 -----------------------

The ZFS Emulated Volume component (ZVOL) enables raw devices from the storage
pool to be presented to userland device consumers.  It therefore requires a
NetBSD-specific device driver.

 1.4 Filesystem Internals
 ------------------------

The ZFS Posix Layer (ZPL) is significantly nuanced and OS-specific.  It is a
very small and very difficult component when compared with the rest of ZFS.  A
detailed blueprint, in the form of a development plan (as described below) will
be composed so that minimal work will be required to complete the ZFS filesystem
layer.

 1.5 Development Plans
 ---------------------

As the adage goes- when one fails to plan, he plans to fail.  Throughout the
entire project, I shall author an iterative development plan.

Development plans will include the following:
  - Function-call diagrams (as needed)
  - Updated Gantt charts illustrating dependencies and contingencies in the
    scope of the project timeframe
  - Required functionality upon completion
  - Optional functionality upon completion
  - File- and function-level summaries of work needed to successfully port each
    portion of code
  - Other specific documentation requested by mentors

Iterative development plans, at the end of the project, shall outline the work
that has been completed and will thusly provide future ZFS maintainers with
detailed documentation of NetBSD-specific features and bugs.


 2 Deliverables
 ==============

In addition to project milestones, I shall maintain a project journal that
outlines day-to-day goals and achievements.  Weekly summaries based on my
written logs and CVS commit messages will enable the project mentors to provide
meaningful feedback regarding my work and prevent potential problems from going
unnoticed.

 2.1 Milestones
 --------------

2007/05/28:	[Project start]

2007/06/03:	Initial development plan

2007/06/17:	Storage Pool Allocator (VDEV, ARC, & ZIO) complete

2007/06/24:	Data Management Unit complete

2007/07/01:	libzpool, ztest, and zdb complete
		[Primary zpool implementation complete]

2007/07/08:	Phase 2 development plan outlining userland management tools
		including:
		- zfs(1)
		- zpool(1)
		- /dev/zfs

2007/07/09:	[Project midterm]

2007/07/22:	Phase 2 implementation complete

2007/07/29:	Phase 3 of development plan outlining ZVOL

2007/08/18:	'Final' development plan blueprinting zpl

2007/08/20:	Project summary and lessons learned
		[Project complete]


 3 About Me
 ==========

I received my bachelors degree in Computer Science from Stevens Institute of
Technology (SIT), where I am currently pursuing a masters degree in Systems
Engineering while working in the School of Sciences and Arts academic system
administration team.  Through the university, I have access to hardware on which
to test my work under Solaris and NetBSD.  My current resume is available here:
	http://www.olix0r.net/resume.pdf

I have been tracking NetBSD-current for over a year, and follow many NetBSD
lists regularly.  Furthermore, I have taken courses with Jan Schaumann and
Hubert Feyrer; and I worked under Jan for over a year and with Thor Simon while
he consulted for SIT.  I have contacted each of these NetBSD developers while
preparing this proposal.  Furthermore I live in close proximity to Thor, which
enables me to meet with him to discuss project matters.

While completing my undergraduate degree, I worked on an eight-month senior
design project designing, implementing (10K+ LOC), and documenting an intrusion
prevention system in C.  Also, I have worked on selective summer-long research
projects with university faculty.

Recently, I have begun to port Fabrice Bellard's KQEMU Loadable Kernel Module
from FreeBSD to NetBSD.  Through this project, I have gained familiarity with
NetBSD's lkm(9), driver(9), uvm(9), and scheduler(9) interfaces.  At this point,
my port of KQEMU has been delayed due to changing customer (SIT) priorities.


  4 References
  ============

[1] Pawel Dawidek's initial post to freebsd-current regarding his ZFS port

[2] NetBSD's ZFS SoC project description

[3] ZFS Porting page

[4] ZFS Source Tour

[5] Solaris ZFS Administration Guide

[6] ZFS On-Disk Specification [Draft]

$Id: ZFS_PROPOSAL.txt,v 1.9 2007/03/26 11:41:20 ogould Exp $
2007/04/03 21:33

This is the bitbucket, which is something you might refer to as a 'blog'. However, if this were any sort of 'real blog', I would update this much more frequently than (I'm sure) I will. I am using blosxom to maintain the bitbucket, as it is very well suited for small sites like this. Blosxom is a Free and Open Source CGI script (written in Perl) that is extremely light-weight and easy to use.

Olix0r.net hosts mail, shell, & www. Accounts are available, at no cost, at request, if I feel like it. My systems run various (late) versions of NetBSD. If you're interested, contact root@ and offer him lots of beer!

2007/04/03 11:37

OLIX0R.NET has undergone a minor update this weekend. Next & previous links have been added to blosxom. Also, I managed to use the word "fuckload" in my bio, which amuses me.

2007/04/01 23:41

Granted- to a certain extent I have been aiming to live a slightly less collegiate life (with cooked meals and everything). I was a little amazed to find myself up a full half-hour before my alarm was supposed to go off. This newfound ability and determination to.. wake up.. also has manifested itself as the inablility to sleep throughout the last week. I guess this is good insentive to be off campus by 6PM, either way.

Beautiful spring day in the making- and this time it is actually spring.

2007/03/29 17:45

The explosion of interest in GUIs since 1984 has had the unfortunate effect of obscuring the virtues of CLIs. The design of consumer software, in particular, has become heavily skewed towards GUIs. While this is a good choice for the novice and casual users that constitute most of the consumer market, it also exacts hidden costs on more expert users as they run up against the expressiveness limits of GUIs--costs which steadily increase as the users take on more demanding problems. Most of these costs derive from the fact that GUIs are simply not scriptable at all--every interaction with them has to be human-driven.

The Art of UNIX Programming, Eric S. Raymond
2007/03/27 09:50

Buenas!

I've got about 2 days left at Casa Verde. Tuesday we leave for San Pedro Sula to catch the early^Wonly flight out on Wednesday. At this point, I'm not ready to leave. There are plenty of things to do here that I have not yet done (like rafting), but these are not the primary reasons why I want to stay. Life here is slower, simpler, and a whole hell of a lot more beautiful. That's not to say that there are not a whole bunch of reasons that Jungle living is difficult, but these pale to the natural majesty of La Cuenca. I'll have to wait to see if the photos do this place any justice.

We bouldered up the river Friday and Saturday morning. The boulders along this river are quite gargantuan, which makes them a LOT of fun to climb. I think that my body was made to do this sort of thing. The first day my ugly sandals were really getting in the way, so I ditched them yesterday and went barefoot. This made it much easier to climb, but when the sun starts to get high overhead, the rocks head up making it a bit more difficult to scramble au natural. When we returned, a little bit battered but no worse for the wear, I felt fulfilled. I could do it every morning.

We never did make it to Roatan. Several setbacks, and a crap ton of rain kept us home for the better part of last week. This, however, is what I like in a vacation-- amazing scenery, natural living, plenty of booze, yoga, and just being. Running around trying to see everything, though surely an enjoyable endeavor, is not a priority to me. Especially as I plan on returning here numerous times-- it will all still be here waiting to be explored.

Whitney has been occupied filling ~400ft of 16mm film. This, however, is not a straightforward process. Point-and-shoot is a lot more of Think-Look-Point-Think-Look-Point Elsewhere-Think-Look More-Point-Shoot. It's fine, though. I am really excited for them to shoot Blondes in the Jungle. I am sure that will be an insane and hellish (and probably HOT) week or two of filming, but I am also fairly certain that it will come out great. If you're the type of person that grants up-and-coming filmmakers money, give them a whole lot! Then again, if you're the type of person who does this, I'd love an email from you-- how did you find this on the web?

I've got a bunch of big decisions to make when I get back home. I am not really fulfilled with my life there. I've known this for some time, but it is increasingly apparent to me that I should not continue if I am unhappy. My job has been unfulfilling; and to continue without any indication of near-term improvement would be self-damnation. City-living is another factor towards my discontent-- I long to live somewhere slower-- I think. When I get back it is at least time to start knocking on a few doors to see what opens itself to me. I've not made up my mind that I want to leave, but I should know what my options are.

Coming to Honduras has been a very powerful experience. I've not been impressed by the local culture, or even the wealth of things to do here. Rather, I've been made more aware of contentness in being-- peace of mind. I imagine that this is achievable in any setting-- even the Nuevo-Police State that is the New York Metropolitan area. However, in order for me to cope, personally, I need to put myself in a more positive environment. Fighting to be happy seems like a lot of energy that I could be putting into something creative.

2007/03/26 23:57
Hola!

Whitney and I arrived here on Tuesday, but this is the first (free) Internet connection I've come across-- at a beautiful hotel on the Atlantic (Carribean?), no less. There are pictures to be posted, but I have not been organized enough to get them onto a computer.

I am sitting on the beach with free 802.11. It's a bit windy an overcast, but this is a very welcome change. I've just eaten fish for the second time here (second time in two years, also). Que Bueno! The three of us (Whitney, m my mother and I) are three beers in and it's just 13:15. We still have to go do some shopping before leaving Town (for more cerveza, primarily).

La Cuenca, my mom's neighborhood, in a way, is a river gorge that ~6000 personas call home, including somewhere between 25 and 100 expats-- I have no idea of the specifics. The first night we were introduced to the local pub-- the Jungle River Lodge is an adventure lodge perched above breathtaking boulders and, of course, a river rapid-- all of this only two doors down from my Mom's Casa Verde.

Yesterday, we traversed the river to visit a Women's Collective that makes crafts-- Whitney and I bought a set or two of napkins with sea creatures. This coming Tuesday, we plan on heading out to Roatan, a mostly-Gringo island about 40 miles off sure. In addition to that, lots of river rafting and waterfall treks-- and perhaps a few other journeys-- are in store for the coming week.

Hasta luego.

2007/02/16 14:37

Function & Desgin
are inextricably entwined.
One without the other:
a brother with no mother-
Father Fuckup close behind.

2007/02/02 00:13
Date: Thu, 1 Feb 2007 10:59:17 -0500
From: ver
To: wbh

On 2007-02-01 03:05 -0500, wbh wrote:

> i hope you are having the sweetest dreams.

I had weird X-File dreams.

The begining of the dream involved something like a camp of people that
I was in.  On this big muddy cliff in a hut without reliable lights.
Whenever the power went out someone would die.  We had to find the
killer, who was either a midget or some weird kid I went to high school
with.  Of course it wasn't the midget.

There was a dog that only ate things the color of money.  And when at
the petfood section of a supermarket I saw something called a 'doggy
salad' which was pretty much slices of ham, lettuce, and tomatoes.  The
dog's owner, some old lady, bought these long rigid tapework-like
(green) dogtreats that at some point later in my dream were
japenese-noodle like worms that were dangling from the dog's asshole
when the dog was dead in a tree.  Fox asked me to retrieve them.  It was
a big dead tree without leaves on a cliff over the ocean.

There was also a midget stuck in the doors of a subway cars, and
hipsters sitting on the subway floor trying to think of things that are
initialed 'MF.'  One of them thought of 'Masculine Feminine.'  The other
thought about something regarding Sherlock Holmes vs Asparagus.

There were also cinderblocks in the trunk of an SUV- i think your
parents.  I buried them in dirt so that I could keep dead X-File bodies
cool until they got to the lab, but there was some problem with this.
Later on when I was on Jeapordy I had to try to explain it to Barbara
Bush and Agent Skinner.

I have no fucking clue.  Get a GPG key so that the CIA doesn't have to
know about my dreams.
2007/02/01 12:59

January the 6th- what a lovely Spring day. This, to me, seems like a very strong shot across the bow to remind us that climate change is a real thing. We unfortunately, no longer seem to have the convenience of time to figure a way out of this rut. We are in it, and it will be dogging us throughout our lifetime.

2007/01/07 01:22
From The Collaborative International Dictionary of English v.0.48 [gcide]:

  Froward \Fro"ward\, a. [Fro + -ward. See {Fro}, and cf.
     {Fromward}.]
     Not willing to yield or compIy with what is required or is
     reasonable; perverse; disobedient; peevish; as, a froward
     child.
     [1913 Webster]
  
           A froward man soweth strife.             --Prov. xvi.
                                                    28.
     [1913 Webster]
  
           A froward retention of custom is as turbulent a thing
           as innovation.                           --Bacon.
  
     Syn: Untoward; wayward; unyielding; ungovernable: refractory;
          obstinate; petulant; cross; peevish. See {Perverse}. --
          {Fro"ward*ly}, adv. -- {Fro"ward*ness}, n.
          [1913 Webster]
2007/01/04 23:43
THE MEATENING!! -- I strongly suggest that you do not send mail to that link.