Bill already answered some stuff so I'll start replies this message :-)

> The problem is that NetBSD can only really deal with one partition type at
> a time. Well, each port has its own scheme (some can support a "NetBSD"
> and a "Vendor OS" table format). The better thing would be for us to be
> able to support many formats in one system. Then all ports could read
> MacOS tables, Atari tables, MBR, etc...

Didn't realize the problem was that deep. I thought we simply couldn't
write disklabels. Ugh! These are problems that can be fixed by folks who
don't need driver writing / hardware hacking skills (*hint* a wider audience
of programmers should be able to work on this, not just us "hardware gurus")

Is this problem being discussed on the "general" kernel list?

> > You want to talk about bizarre... I looked in the Mach Kernel from MkLinux
> > in the hopes of porting that (read-only) HFS code to NetBSD....  It's
> > literally a wrapper around hfsutils.  The Mach Kernel apparently has a
> > means of accessing a filesystem on a file-by-file basis w/o knowing about
> > the structure of the filesystem... and that takes advantage of it.  No
> > chance that NetBSD has any capability like that, is there?
> 
> NetBSD has the same type of setup. They're called vnodes. :-)
> 
> I thought hfsutils had some sort of licensing restriction...

Good point. I wonder how they do it in MkLinux since they have the CMU
license which doesn't allow GNU code either. Perhaps they can hook user-land
utilities into the file system? In that case they could include htools
with the install stuff. I can't see why we couldn't do that. After all,
we include gcc and other gnutools in the user land. Just as long as they
don't go in the kernel everything should be OK.

However, my point was that we could build an installer utility ourselves.
Building a read-only utility should be signifigantly easier than one that
has to write as well. All we'd need is an HFS ls, cat, and copy to do installs.
There's that ancient HFS program from the Alice days that is basically a
read-only tool which did both ls and copy. We'd still need cat so we could
pipe the output to tar and gzip.