On Sun, 12 Apr 1998, Michael R Zucca wrote:

> > After a few hours of hacking, I've managed to get Apple's (MkLinux's) 
> > pdisk to compile and partially work (haven't tried writing anything yet,
> > only reading, don't want to hose my drive... need to find an old drive to
> > hork....)  Getting it to compile was a bit of a drag, but nothing too
> > complicated.
> 
> Ok. Looks like I stand corrected. I assume pdisk does its magic via direct
> calls to the SCSI code?

I'm not sure how it works.  It generates a bunch of illegal requests at
the onset... like twelve of these lines in a row (I wrapped the line into
two).

sd1(sbc0:6:0): illegal request,
              data = 00 00 00 00 21 00 00 00 00 00 00 00 00 00


at least with the sbc kernel.  I assume it would do the same thing with
the ncrscsi, but I'm not sure.

I *think* it actually treates the device file as if it were a file, hence
the rather extensive use of lseek, thus lending greatly to the portability
of the program.  Not positive about the specifics, though.

The big worry I have is the last part that I had to comment out....  Under
MkLinux (and linux-pmac/ppc), pdisk issues an ioctl which causes the
vmlinux server/kernel (and possibly the Mach Kernel, but I'd assume not) 
to reload the partition table.  This raises an important question.... 
Does NetBSD cache information about the partition structure of the drive,
and would it freak out royally or misbehave if that structure were
changed... and more importantly, would it be able to recognize new
partitions that were created without rebooting?  If not, then there's
still one small kernel-level snag, albeit a small one.  Anybody know?


> Looks like with enough work with userland stuff somebody aught to be able
> to hack together a native install disk with a booter and a kernel with
> a miniroot of some sort.
> 
> Any takers?

If nobody does it before the summer, I'd be glad to code something.
Better still, assuming the sources for the x86 platform's installer stuff
is available, it ought to be modifiable with a bunch of #ifdefs for
mac68k's purposes.

Here's another question... about the vnodes and hfsutils... is there
anything preventing an lkm using basically the Mach Kernel's hfs support
code and adding write support and updating to a more recent hfsutils?  Any
takers?


David

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/CC/FA/H/L/MC/M/MU/PA/TW d-@ s:>- a-- C++++>$ UBLAS*++++>$
P+?>$ L+++>$ !E--- W+++>$ N++(+++)>+++$ !o? K-? !w--- !O
M++>$ !V-- PS+>$ !PE- Y+>$ PGP+>$ t+++>$ 5+>++++$ !X- !R tv+>$
b++>$ !DI !D- G++(+++)>$ e>++++ h--! r--- !y-
------END GEEK CODE BLOCK------