Thanks - I'll try to tweak the pages a little :)


		David/absolute

On Fri, 31 Dec 1999, Simon Burge wrote:

> [[ David - CC'd to you in-case there's anything that may be useful
>    in here to put on the www pages somewhere :-) ]]
> 
> Richard Michael wrote:
> 
> > I noticed the conversation between Simon and Dan regarding
> > update to the sys/dev/tc/asc_ioasic.c file - specifically
> > updating from rev. 1.15 to 1.15.2.1 and after looking on 
> > the ftp site, I am somewhat confused about the whole matter.
> > 
> > I just built a new kernel from:
> > /pub/NetBSD/NetBSD-1.4.1/source/sets/syssrc.tgz
> > 
> > but upon inspection I see it contains the old asc .c file.
> 
> Correct - this file contains the source code at the time of the 1.4.1
> release.  It will never change.
> 
> > Since,
> > /pub/NetBSD/NetBSD-current/tar_files/src/sys.tar.gz (25/12 @ 13:45)
> > and
> > /pub/NetBSD/arch/pmax/snapshot/1.4.2_ALPHA/source/sets/src.tgz
> > 						(27/12 @ 12:00)
> > 
> > are both development (the latter is a 1.4.2 ALPHA, what about
> > NetBSD-current?), which should I use for a bleeding edge kernel?
> > (Not necessarily a stable one.)
> 
> This crops up a lot :-(
> 
> I _thought_ we had a description on a web page somewhere but I can't
> place it right now.  In a nutshell, 1.4<letter> (eg, 1.4A, 1.4P) is
> the "bleeding edge" and this is called "NetBSD-current".  1.4.<number>
> is "stable" with well proven patches and non-significant changes, but
> should functionally be little different to 1.4.  Upgrading a 1.4 machine
> to 1.4.1 or NetBSD-release shouldn't cause any user-visible changes.
> 1.4.2_ALPHA should me more stable (and more secure because it includes
> the latest BIND code) than both 1.4 and 1.4.1.
> 
> So:
> 
> 	1.4   -->   1.4.1
> 	1.4A        1.4.2
> 	1.4B
> 	 ..
> 	1.4P
> 
> Developement (the "bleeding edge") continues down the first column,
> while bugs and security fixes are added to the second column.
> Eventually the first column will turn into 1.5 or 2.0 (whichever version
> number we choose to move to next time there's a major release).
> 
> So the "bleeding edge" is pub/NetBSD/NetBSD-current and the "stable" is
> in pub/NetBSD/NetBSD-release.
> 
> 
> One more thing - I believe Dan was working with 1.4.1, so his
> NetBSD-release version of sys/dev/tc/asc_ioasic.c would need to be at
> revision 1.15.2.1 to include the DMA fix.  If he were using NetBSD
> current, he would need to be using rev 1.18 or later.  From this, we can
> see that 1.4.1 is based on rev 1.15 of the file, while the "bleeding
> edge" is up to rev 1.18.  The differences between 1.17 and 1.18 (the DMA
> fix) were added to rev 1.15 creating 1.15.2.1.  Hmm, does this paragraph
> help?
> 
> I really hope the above is as clear as mud!
> 
> > Also, there's this file:
> > /pub/NetBSD/NetBSD-release/tar_files/src/sys.tar.gz
> > 
> > Since this a daily snapshot of the release branch, should
> > I assume that it is of the 1.4.1 release?  Why is there a
> > 1.4.2 changelog in the directory if 1.4.2 is only alpha?
> 
> This is the "1.4 branch" or "stable" to use another term.  The 1.4.2
> changelog is a list of what has changed since 1.4.1.  When 1.4.2 is
> released, we'll then maintain a 1.4.3 changelog which will then list
> everything that has changed since the 1.4.2 release.
> 
> > I see that there are no patches in:
> > /pub/NetBSD/arch/pmax/patches/
> 
> > To what source tree would these patches be relevant?
> 
> This directory contains random patches.  Hopefully a README file would
> describe what they are applicable to.
> 
> > What source set should I use for the latest stable kernel?
> > I would guess the NetBSD-release source, since I notice it
> > contains the asc_ioasic.c 1.15.2.1.
> 
> Yup!
> 
> > --
> > Another issue:
> > For the build of the 1.4.1 kernel that I mentioned above,
> > I commented out this line in my CONFIG file:
> > 
> > #pseudo-device   fb               1      # up to 3 framebuffers
> > 
> > since I don't have a framebuffer, nor will I need one.  The build
> > failed errors in the link stage.  I don't have them copied out,
> > but would be happy to reproduce them.  My question is just why
> > it failed.  Is there something I mis-cfg'd (does something else also
> > need to be commented out) ?  Once I uncommented the line, kernel
> > built fine.
> 
> I'd guess you also need to comment out the following lines to (from the
> -current GENERIC config file):
> 
> 	mfb*    at      tc? slot ? offset ?     # PMAG-A MX Monochrome Framebuffer
> 	cfb*    at      tc? slot ? offset ?     # PMAG-B CX Color Framebuffer
> 	sfb*    at      tc? slot ? offset ?     # PMAGB-B HX Smart Framebuffer
> 	px0     at      tc? slot ? offset ?     # PMAG-C PX family
> 	xcfb*   at      tc? slot ? offset ?     # PMAG-DV Color Framebuffer at MAXINE
> 	pm*     at      ibus0 addr ?            # 3100 onboard fb
> 
> 	pseudo-device   rasterconsole    1      # NB: raster console requires "fb"
> 
> All of these relate to framebuffer type things.  If you still have
> problems after this, please include your error output and that should
> help narrow things down.
> 
> Simon.
>