David Brownlee <abs@netbsd.org> wrote:
> >    So you like duplicating a huge source file to change one line, don't
> > you?
>
> It could be she prefers to have the option to configure the
> kernel for a faster, cleaner codepath, or maybe just the basic
> supportability of having a machine independant chip driver, with
> specific attachment code for each of the _different_ environments.
   
   This happens to be correct in this particular case (ncr driver in
NetBSD) simply because there ALREADY is a completely MI NCR 5380 driver. If
this were not the case, the argument would be invalid, and Allison's
statement seemed to be general, rather than specific to this case.
   
> Incidently this may hold an answer to why the later VS3100 SCSI
> driver would not be immediately viable on the VS2000 - the 3100
> had a larger 128KB buffer which quite possibly should be accessed
> in a different fashion, plus the DMA setup is obviously different.
   
   OTOH, this driver sharing is already implemented in Ultrix and VMS for
the HDC driver, indicating that the DMA differences are handled at a lower
level. Since the DMA logic is external to both SMC HDC9224 and NCR 5380
(the built-in logic in the former is not used) and shared between them, the
same could easily be done to the NCR driver.
   
> If there was a compelling hardware reason why the address _had_
> to be different on a later machine then Ultrix could quite easily
> have coped - it would just have had to try an additional match.
   
   The kernel config file lines for the MFM subsystem look like this:
   
> controller sdc0 at uba0 csr 0x<some 32-bit address> vector sdintr
> disk rd0 at sdc0 drive 0
> disk rd1 at sdc0 drive 1
> disk rx2 at sdc0 drive 2
   
   (Replace <some 32-bit address with the actual address. I'm not sure
about the name "sdintr". I don't have networking set up on my Ultrix box
yet, so I can't log into it to look at the file and quote the exact lines,
but they are similar enough.)
   
   ("sdc" is the Ultrix designation for the HDC controller. It has nothing
to do with the "sd" designation for SCSI disks in NetBSD and other OSes. I
will say more about this in another post about Ultrix's treatment of
BabyVAX mass storage subsystems, which I will make when I get the man pages
installed on my Ultrix box and use them to learn a little more about the
issue.)
   
   If the HDC controller address on the KA42 SCSI/MFM daughterboard were
different from the one on KA410, the following extra line would be needed:
   
> controller sdc1 at uba0 csr 0x<some other 32-bit address> vector sdintr
   
   This would in turn require the following three extra lines:
   
> disk rd3 at sdc1 drive 0
> disk rd4 at sdc1 drive 1
> disk rx5 at sdc1 drive 2
   
   The rd and rx unit numbers would be different between the two
configurations, and on one of them they would be different between Ultrix
and VMS/VMB, making the matters complicated and confusing.
   
> >    It surely is! The way the hdc driver checks for KA410 and refuses to
> > load if it's something else smells like (heaven forbid!) artificial
> > blocking... :-)
> >
> Or convervative programming from someone with limited access to
> different hardware, and who is more than willing to help anyone
> else interested in working on the driver...
   
   What's wrong with you people, that was intended to be tongue-in-cheek...
   
> Could I further suggest you intensively concentrate
> on the above, excluding all further port-vax emails until you
> have finished.
   
   That's what I'm trying to do. However, if someone else brings up a topic
directly related to this, I need to participate in the discussion, as that
will benefit my work. In the long run it may also benefit NetBSD if someone
decides to port my work to it.
   
> You amaze me - most of us remain significantly impressed by what
> Bertram managed to achieve on so little documentation, while
> you dismiss it above with an arrogance that borders on contempt [...]
   
   I have full respect for Bertram and his work. Actually, it is this work
that has caused me to look at NetBSD in the first place (and join this
list). As you may remember, I was originally considering this support to be
of excellent quality and even planning to use it myself temporarily until I
finish mine. However, by reading this list for a few months, I have learned
about a host of problems with it, and when I actually looked at the code
myself, I was shocked a little.
   
> [...] and then have the gall to ask him for copies of his documentation.
   
   Where was I asking for copies of anything?! I was simply curious whether
he has used the datasheets from SMC and NCR. I for one definitely will.
   
> You also insult Alison, one of the few other people still talking
> to you on this list.
   
   I don't see anything in my postings that could be insulting to her or
anyone else, but I sincerely apologize if there is something.
   
> I suggest you setup your own listserver for your OS and related
> matters [...]
   
   Sure, tell me who would be willing to archive it.
   
> [...] and then refrain from posting to
> this list again. You would be doing us all a great service.
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   
   To you maybe, but not to the poor guy who has just acquired a VAX that
is not very well supported by NetBSD and is asking this list for help,
SIMPLY UNAWARE of the fact that he can spend as little as $100 on a license
and get much better support for his hardware.
   
   But really I don't remember mentioning my OS of choice in this thread
about BabyVAX mass storage subsystems at all. Sure, I mention my work and
you all probably know that it's for 4.3BSD-*, but nothing prevents you from
porting it to NetBSD.
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu