Removing __BROKEN_CONFIG_UNIT_USAGE

cubecubidou.net wrote:

> Attached is a patch that should DTRT and allow us to
remove the
> __BROKEN_CONFIG_UNIT_USAGE tests in subr_autoconf.c.
> 
> My understanding of the sun3 code is that it used it to
make sure the
> xd and xy drives had the correct numbers, while still
having a wildcard
> instance in the config file, which is not only wrong
but confusing.

I have not checked your patch closely, but
arch/sun3/sun3{,x}/vme.c also have broken cf_unit usage.

The "real" solution is to switch sun3 port to MI
vme(4) as sun2,
but it requires to rewrite all framebuffer drivers for sun3
to use MI sun drivers.
(I've done bus_space(9) and bus_dma(9) for sun3, but
 for the rest more motivation is required..)
---
Izumi Tsutsui

On Mon, Jul 16, 2007 at 04:53:09PM +0200, Jachym Holecek
wrote:
> # Izumi Tsutsui 2007-07-16:
> > cubecubidou.net wrote:
> > 
> > > Attached is a patch that should DTRT and
allow us to remove the
> > > __BROKEN_CONFIG_UNIT_USAGE tests in
subr_autoconf.c.
> > > 
> > > My understanding of the sun3 code is that it
used it to make sure the
> > > xd and xy drives had the correct numbers,
while still having a wildcard
> > > instance in the config file, which is not
only wrong but confusing.
> > 
> > I have not checked your patch closely, but
> > arch/sun3/sun3{,x}/vme.c also have broken cf_unit
usage.
> 
> A quick grep through sun3 configs shows vme only ever
has wired instances,
> so it would seem it's not broken in the
__BROKEN_CONFIG_UNIT_USAGE sense.

Exactly.

Yes, sun3 still relies on cf_unit to carry information, but
it's not
alone in that respect.  As long as that kind of abuse is
limited to
wired instances, it's ok.

-- 
Quentin Garnier - cubecubidou.net - cubeNetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2,
2005.

On Mon, Jul 16, 2007 at 10:34:32PM +0200, Matthias Drochner
wrote:
> 
> Looks well so far, just a minor nit:
> 
> cubecubidou.net said:
> > +xy0 at xyc0 drive 0
> > +xy1 at xyc0 drive 1
> > +xy2 at xyc1 drive 2
> > +xy3 at xyc1 drive 3 
> 
> The drive number should be a locator which is local
> to the parent instance. Probably:
> xy0 at xyc0 drive 0
> xy1 at xyc0 drive 1
> xy2 at xyc1 drive 0
> xy3 at xyc1 drive 1 

Yes, should.  It means more changes to the driver though


> > +	for (xa.driveno = 0, locs[XDC_DRIVE] = 0;
xa.driveno < XDC_MAXDEV;
> > +	    xa.driveno++, locs[XDC_DRIVE]++)
> > +		(void) config_found_sm_loc(self,
"xdc", (void *) &xa,
> > +		    xdc_print, config_stdsubmatch);
> 
> It should only report the drive number(s) relatively to
the local bus.
> Didn't look too closely, and don't know the hardware.
As it looks
> there are at most 2 drivers per controller, but it
doesn't know which
> if them are present. So I'd assume a loop from 0 to 1
would do it.
> XDC_MAXDEV should die.

Well, at the point the better is probably to make it so the
numbering of
the units doesn't necessarily have to be that way (i.e., 0
must map to
[0,0], etc.).  Again, larger, more intrusive change.

-- 
Quentin Garnier - cubecubidou.net - cubeNetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2,
2005.

... does anyone actually have SMD disks, or even
controllers, to test?
I pitched my disks a decade ago, and the controllers three
years ago.

	- Nathan

On Mon, Jul 16, 2007 at 08:18:12PM -0400, Nathan J. Williams
wrote:
> 
> ... does anyone actually have SMD disks, or even
controllers, to test?
> I pitched my disks a decade ago, and the controllers
three years ago.
> 
> 	- Nathan

http://mail-index.netbsd.org/port-sun3/2007/02/04/000
2.html

That wasn't so long ago.  Now, if it was up to me, I'd cvs
rm a lot of
stuff...  (Un)fortunately, it's not just up to me.

-- 
Quentin Garnier - cubecubidou.net - cubeNetBSD.org
"You could have made it, spitting out benchmarks
Owe it to yourself not to fail"
Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2,
2005.

On Monday 16 July 2007, Nathan J. Williams wrote:
> ... does anyone actually have SMD disks, or even
controllers, to
> test? I pitched my disks a decade ago, and the
controllers three
> years ago.

Yes.

I still haven't been able to successfully boot a NetBSD/sun3
installer 
on my 3/180.

Pat
-- 
Purdue University Research Computing --  http://www.itap.purdu
e.edu/rcac