> At 12:24 PM 3/1/94 -0500, Gregory Kritsch wrote:
> 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.

I'm not arguing that you have a bad idea - in it's own way, it's a good idea.
It's not an idea that I would personally choose, but that by no means makes it
wrong.

My opinion on design is that one should place as few constraints as possible
on a system.  In my view (and yes, this is a very much more nitpicking than
a majorly significant important point), constraining users to allocate 3
sectors so it looks like an AmigaDOS disk is a bad idea.  Allowing them that
choice is a good idea.

An additional note to the original idea - is a similar scheme possible for
MS-DOS floppies, which could be plugged in through the d partition of the
WD sector format driver?

I will admit to being quite ignorant of the actual semantics of device
programming under NetBSD.  I don't think it would be significantly more
work to implement 4 partitions, as compared to 2 or 3.  If I'm wrong,
would someone please correct me (someday I'll want to be non-ignorant of
the actual semantics of device programming, hopefully within the next
six months).

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

Okay, sorry, you're right.  The special code we need will be in newfs-type
programs, not fdformat (it's been a while since I've had a Sun to play with,
I forgot).

I'd like to say that, in general, all the ideas that have been discussed so
far about floppy disk drivers have been very interesting.  Everything from
the just fake a disklabel for the whole disk through to floppies that have
multiple partitions (hey, can anyone think of a way to make a BSD partition
look like a file on an AmigaDOS disk - might be useful for the installation
distribution).  Even the idea of uniquely identified disks being placed in
multiple drives was interesting, if (again, in my opinion) a little impractical
in some situations (and no, please don't argue the point with me).

Rather than spending N days here quibling about what ideas to implement, why
don't we try to come up with a mechanism whereby we can implement ALL of these
ideas?

> Cheers

Gregory

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