Bertram Barth <bertram@ifib.uni-karlsruhe.de> wrote:
> Just for completeness: on my home-machine I found a file
                         ^^^^^^^^^^^^^^^^^^
>         -rw-r--r--  1 bertram  users  40829 Jul  9  1997  vsbus.c
> [...]
> PS: I also found "ka420.h" dated Oct 14  1996, so what's the prob?
   
   The problem is with the underlined part. If the version of vsbus.c you
are talking about were in the distribution, the problem that so many people
on this list have been burned by wouldn't exist. Judging from the date on
your file, these people have been suffering for no reason for almost a
whole year. This is a good example of the NetBSD developers' organizational
level.
   
   This also reminds me of an old Chinese tale my father has once told me.
Once during a war a Chinese peasant has come to the emperor and told him
that he knows how to defeat the enemy in three days, but didn't tell how.
The emperor agreed to give the peasant a chance, but warned him that if he
fails he would be beheaded. During all these 3 days the peasant was doing
nothing to defeat the enemy. The emperor is ready to execute the peasant
when on the third night there is a thick fog. The peasant suddenly turns
out to be well-prepared for the fog and uses it to win a major battle. The
next morning the emperor and all his people are amazed by this and don't
know how to thank the peasant. Then one of the emperor's widest advisors
says that he also knew that there would be a thick fog that night. The
peasant answers: "Your knowledge did not bring our country any good, and
therefore its existence is irrelevant."
   
   As for the header file, it is in the distribution, but it is not
included by any source file in it. I also strongly doubt that you have
arch/vax/vax/ka420.c in your arsenal.
   
> PPS: from the beginning booting from SCSI worked only via "rom()/netbsd"
   
   I know this. The reason the stock kernel can't boot from SCSI disks on
KA42/41 is not because you can't bring the kernel into memory, but because
the kernel can't mount the root filesystem (simply because it can't do
anything with SCSI).
   
   Sincerely,
   Michael Sokolov
   Phone: 216-368-6888 (Office) 440-449-0299 (Home) 216-217-2579 (Cellular)
   ARPA Internet SMTP mail: msokolov@blackwidow.cwru.edu
   
   P.S. Of all ongoing NetBSD works the one I appreciate the most is Jay
Maynard's work on SGEC and KA670. Keep up the good work, Jay! The only
concern I have is that it would be a great pity if this work causes another
"jump". Right now in NetBSD there is a Chinese wall between the Q-bus VAX
(KA630 and KA650) and BabyVAX (KA410, KA42/41, and KA43) support code, and
I haven't seen any indications that Jay is planning to change this. What
everyone should realize is that these new Q-bus VAX CPUs like KA660 and
KA670 combine both Q-bus and BabyVAX elements, and developing any new
drivers for chips like SGEC and SHAC without first restructuring the code
would be a bad idea. If the SGEC driver is written in a way that is tied to
the existing KA630/650 code, NetBSD would have problems in the future if
someone decides to support KA50, a BabyVAX system board with an SGEC chip.
OTOH, some Q-bus VAX CPUs actually have LANCE chips just like the
currently-supported BabyVAXen do. KA640 is the primary example. Therefore I
strongly advise you to first restructure the BabyVAX code to make it
possible to support chips like LANCE when they are found on a Q-bus VAX
CPU, develop full support for KA640, and only then tackle things like KA660
and KA670, using the SHAC driver developed for KA640 and making the new
SGEC driver applicable to both Q-bus VAXen and BabyVAXen. Not doing so and
"jumping over" KA640 or other intermediate boards would leave a hole in the
chain of supported systems that may very well later become a sore like the
KA42/41 SCSI.