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.
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.
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.
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.
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.
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.
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@...>.
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.
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.
