Bill Studenmund <wrstuden@nas.nasa.gov> wrote:

>On Fri, 23 Jul 1999 nigel@ind.tansu.com.au wrote:
>
>> > Why do you need to use the actual FFS code?  If this is for a boot
>> > program, use the FFS reading package in libsa.
>> 
>> 	I also want UFS, and ext2fs, and maybe LFS in the future.
>> Having the booter do a mountroot() in exactly the same way as the
>> kernel does it will be best, since device names will match, et c.
>
>ufs isn't a real, on-disk fs anymore. It represents the code common to
>ffs, lfs, and ext2fs. For instance, ffs and lfs use the same directory
>format, and both use the ufs_lookup routine.
>
>If we're talking the booter, I'd vote going for libsa. If we're talking
>installer, then I'd vote doing both the same, and going your present
>routie. :-)
>
>> > You could certainly also add simple write support to the libsa FFS
>> > package.  I mean, it's not like you have to interact with the buffer
>> > cache, deal with the vnode layer, etc. in a boot block :-)
>> 
>> 	Looking at the (lack of) speed of the current Installer, the
>> buffer cache is _exactly_ what we need!
>
>How is the install-under-NetBSD track looking? I know Collin did a lot
>with it for 1.4. :-)

There are a couple of problems with it that I found when I was upgrading 
my system.  There's a typo in one place (probably my fault from my 
original code), and there's a problem that the newly created Disk 
Partition Map isn't copied into the in-core tables after being written to 
disk.  They do get created properly and written to disk, but the system 
needs to be rebooted before they take effect.  I'm hoping to look into 
that this weekend and see what I missed when I copied the base code from 
the i386 port.

The other problem that remains is there isn't any kernel or loadable 
module support for HFS yet.  We'll need to get that one fixed before we 
can be totally free of the Mkfs and Installer applications under MacOS.

-bob