At 12:24 PM 3/1/94 -0500, Gregory Kritsch wrote:
>> > Probably the best way to do this is to have the disklabel faker routine
>> > report two partitions, a which skips track 0, and c which covers the
>> > whole disk.  You'd use 'a' in conjunction with adosfs, and 'c' with tar,
>> > msdosfs, ufs, and everything else.
>>
>> You mean block 0, right?  I don't want to skip a whole track!
>
>Random thought based on SunOS:
>
>Suns have three ``partitions'' on their floppies - a is track 0,
>b is tracks 1-79, and c is the whole disk (a and b might be reversed).
>I've never quite understood why, but...
>
>The Amiga FFS reports the disktype as the first four bytes of sector 0
>on the disk.  Workbench displays icons labelled DF0:KICK (for example)
>where KICK is a copy of those four bytes.  DF0:BSD_ would certainly make
>me think the disk is formatted.  So there's a use for the a/b mpartitions
>(stick BSD_ in a and use b for tar or ufs).
>
>Most of the time, I can remember not to randomly format disks tha aren't
>AmigaDOS (maybe it's because I use raw floppies for tar and MS-DOS disks
>on a regular basis).  If it becomes a problem, I can even stick a label on
>them saying ``NetBSD disk''.  This seems a much better solution to me than
>wasting a bunch of sectors on the disk.
>
>However, if someone really wants to get fancy, have a magical d partition
>which skips track 0 and track 40, or the relevant portions thereof.  Now,
>except for the fact that we need some special code in fdformat to produce
>a d-partitioned disk, I think everyone can be happy.
>
>> David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto
>> email: dej@eecg.utoronto.ca, finger for more info/PGP public key
>
>Gregory

I pretty much said what I had to say...  I see no reason why to do anything
in netbsd (or any unix development) that could be done better.  Just
because unix
is shit in some implementations doesn't mean that netbsd should also be
shit.  The key is to maintain a high level of compatibility so we can
easily port software from other unices (or written for netbsd).  And we
want unimplemented
(so far) parts of netbsd to work as device drivers are implemented (MSDOS FS,
for example).  To quibble over 3x512 bytes is pretty stupid, IMO.

What those 1536 bytes of an 880K floppy disk buy us is a LOT.  The very first
time someone wipes out an important disk because his label was wrong and the
netbsd floppy driver was not implemented as good as it should have been, that
user will curse the guy who wrote the driver.  The first time you are in the
desparate need of floppies to do an urgent backup and stick your tar disk in
the drive and realize it's really got (important) data on it and decide not
to let quarterback write all over it, you will be thankful.  And yet another
reason to use those 1536 bytes the SMART and USER FRIENDLY way is that you will
be able to use ADOS DiskCopy program to duplicate netbsd+tar created floppies.
Don't use the 1536 bytes the right way, and you won't.

If that 1536 bytes is really that important, then we really should consider
yet another alternative.  You see, the trackdisk hardware is capable of
writing one
big sector on the disk with no (or very small) gap at all.  You can get far
more than 880K (and more than 1536 bytes) on a floppy.  I mean, why not
have 3 formats of floppy (well, more than 3 considering higher density
drives...)?

Again, if you're gonna stick the same disk in the drive under ADOS and NetBSD,
and since we're already considering the ADOS implications (trackdisk format),
we should have a driver that does the right thing.  And the amount of "work" to
do the right thing in the driver is a single "if" statement in C and not
more than a minute or two of programming effort.

As for fdformat, it has to do NOTHING special to handle different flavors of
trackdisk formatted disks.  If it writes sector 0 and the two sectors on track
40 the _right_ way, when you ADOS format it (we will need an ADOS/newfs anyhow)
the disklabel and bam will be initialized for ADOS filesystem.  If you don't
ADOS format it, you can tar 880K-1536 bytes on the disk and still use ADOS to
diskcopy it, do ADOS info on it, etc.

Cheers



------------------------------------------------------------------------------