home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / bsd / 2975 < prev    next >
Encoding:
Text File  |  1992-07-27  |  2.1 KB  |  41 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!sdd.hp.com!zaphod.mps.ohio-state.edu!uwm.edu!rpi!greg
  3. From: greg@ecse.rpi.edu (Greg)
  4. Subject: Re: 386bsd-0.1: primary bootstrap (wdbootblk.c) problem & fix.
  5. Message-ID: <greg.712267214@hibp1.ecse.rpi.edu>
  6. Keywords: 386bsd boot bootstrap wdbootblk.c
  7. Nntp-Posting-Host: hibp0.ecse.rpi.edu
  8. References: <greg.712111605@hibp1.ecse.rpi.edu> <1992Jul27.172708.3363@gateway.novell.com> <greg.712261295@hibp1.ecse.rpi.edu> <1992Jul27.192502.15727@gateway.novell.com>
  9. Date: Mon, 27 Jul 1992 20:00:14 GMT
  10. Lines: 29
  11.  
  12. terry@npd.Novell.COM (Terry Lambert) writes:
  13.  
  14. >In article <greg.712261295@hibp1.ecse.rpi.edu> greg@ecse.rpi.edu (Greg) writes:
  15. [ stuff deleted ]
  16. >however, the status register being polled after the delay is wd_status,
  17. >and I still believe that a canonical fix would be looking at wd_altsts
  18. >instead.
  19.  
  20.   When I first read about the other patch, I did try checking wd_alsts
  21. rather than wd_status. Not knowing didley about the disk controller,
  22. I'm not sure what the difference between these two registers are. 
  23. But, being a shameless hacker, I tried it anyway. Alas, this was no 
  24. help. It was at this point that I resorted to my ugly hack.
  25.   It may be that the wrong register is checked. If so, then there is also
  26. another problem. I'm sure someone more knowledgeble than I will shed some light on this situation soon.   
  27.  
  28. >    The confusion seems to have originated from the various paths in
  29. >the boot and non-boot sections of the kernel which lead to files of the
  30. >same name.  I would suggest that any future patches refrain from the use
  31. >of relative paths to identify the file being patched.  In particular, it
  32. >would be nice if they contained the full path from the root of the volume
  33. >("/") rather than something like "./xxx/yyy/zzz.c", which assumes they are
  34. >starting in the same directory that patch poster did.
  35.  
  36.   Point well taken. In the future I will use full paths, in order to
  37. avoid confusion. This sounds like a policy that everyone should follow.
  38.  
  39.             -Greg               greg@megas.ecse.rpi.edu
  40.  
  41.