--nextPart1467703.MZbQM7RjYc
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 30 January 2006 2:52 am, you wrote:
> In article <200601281113.12131.garrett_damore@tadpole.com>
>
> garrett_damore@tadpole.com wrote:
> > I figured it best to minimize arbitrary changes.
>
> Ok.
>
> BTW, it's better to add config files to src/etc/etc.evbmips/Makefile.inc
> so that autobuild could find any MD fallout.
>
> > > > +options	_MIPS_PADDR_T_64BIT
> > >
> > > This should be in <machine/types.h> or each config file?
> >
> > As far as I can tell, userland binaries are not impacted.  At least I'm
> > able to use most of the usual tools that grovel kmem -- ps, top, netsta=
t,
> > vmstat, etc.
>
> Unless it's defined in <machine/types.h>, I guess LKM would have
> compatibility problem.
>
> I think most modern embedded mips CPUs have R4K style MMU,
> it's OK to add #define _MIPS_PADDR_T_64BIT into
> evbmips/include/types.h like arc port.

I had asked this question to SimonB earlier, and at the time he suggested t=
hat=20
I not do this.  I of course would prefer to have it as you suggest, because=
=20
it avoids having paddr_t be different for different compiles within evbmips.

I hadn't even considered LKM, so this is another compelling reason.

I'm going to reassert this question, and if we can't get <machine/types.h> =
to=20
have this for evbmips, then I may just give up and make a new port (aumips)=
,=20
which is something I proposed a long time ago.

> > Even if I switch to a case table, I still need to have #ifdef's around
> > each case, as the necessary processor support routines may not be
> > included in the config file.
>
> Hmm, IMHO, *_match() function should not do any initialization.
> Could it be a simple compromise to rename *_match() functions
> to *_init() or something?

Yes, except right now the _match() routines aren't doing any initialization=
=2E =20
All they do is either return null (if no match is found) or return a pointe=
r=20
to a table listing the on-chip devices.

> > Anyway, I'll make the conversion if there is sufficient belief that I
> > should do so, but right now my first preference is to leave it as is.
>
> Yeah, you are right :-)
>
> > > all __volatile has been changed to volatile recently?
> >
> > I noticed that it had.  I guessed this is to make us more strictly C99
> > conformant?
>
> perry changed most of them recently.
>
> > > > +#define	AU_WIRED_EXTENT_SZ	EXTENT_FIXED_STORAGE_SIZE(10)
> > >
> > > This value could be smaller. The static strage is only required
> > > by devices mapped before VM is initialized, i.e. only some
> > > console devices do. During cpu_configure(9) (after MD cpu_startup())
> > > we could pass EX_MALLOCOK to extent(9).
> >
> > Frankly, this is the result of my not being entirely confident in a few
> > things:
>
> arch/arc/arc/bus_space.c:arc_bus_space_malloc_safe() might help?
> I think we can use malloc(9) after uvm_init() in kern/init_main.c:main(),
> so you can change flags for extent(9) in cpu_startup().
>
> > Anyway, for now I'd prefer to leave it alone, and then possibly change =
it
> > later after a commit if we are confident that it is safe to do so.
>
> No problem :-)
 =20
OK, so that's the course of action on record. :-)  (Commit as is and change=
=20
later as needed/desired.)
>
> > > > +#if defined(__MIPSEB__)
> > >
> > > Isn't it better to use "#if _BYTE_ORDER =3D=3D BIG_ENDIAN"?
> >
> > Possibly.  The code will only ever be used in mips, so it probably
> > doesn't matter, other than to suit taste.
>
> Most (all?) other sources use _BYTE_ORDER, so maybe it's better.

OK, I'll change that one.

> > > "_chipdep" is needed for these files?
> > > Just au1xx0.c and au1[015][05]0.c look fine for me.
> >
> > I prefered the longer name for two (admittedly weak) reasons:
> >
> > 	1) it reflects that these files really are specializations of chipdep
> > 	2) it avoids possible filename conflict in the build system later.
>
> There is no strict rules, but alpha and pmax use dec_3100.c etc.,
> arc uses c_nec_pci.c (chipset?) and p_nec_jc94.c (platform) etc.,
> and prep uses ibm_6050.c etc. But if any namespace conficts are
> expected in the future, it's no problem to leave them.

I'll leave them alone for now, as there is no reasonable rule to follow.

> > OK, so I want to get a little more consensus, if possible, unless you
> > feel confident in saying it is safe for me to commit.
>
> Well, you could ask:
> "If there is no objection I'll commit the diff in next week"
> or something like this ;-)

I'm going to do that.
>
> Anyway, all changes in your patch only affect MD evbmips and alchemy
> files (BTW any other ports which use MI mips bus_space?) and
> there is no API change exported to MI part, so it's safe to commit.
> Any style issue could be fixed later, though (bad) API can't
> be changed easily because of possible compatibility problem.

Yes.
> ---
> Izumi Tsutsui

=2D-=20
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191

--nextPart1467703.MZbQM7RjYc
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (SunOS)

iQEVAwUAQ95Vy/49Sp1nAoU7AQIQngf/Szf0pQd8KLsE3+ivpMOeV4yfE3uXFr21
iiV9zVSiDwzHHdARVSlg+f+TFTynP8lMT3BQMbpOzWsqaM2KAs8pDYCGH5aTreAN
qHH24yab/hb5xySwUINdPUhj0iYa2DaYKmGq/+JaO4nyOZyYlYdsQVPAquqSqhjK
i4foV5zY422o0dQWy5T8amAyJ52AaBWZDx6AE/vQ3fJtowl10LC4RGZi7eW3Cd09
3M0zqUv9ikQoJe4xLDtJnsO73rh2DtWcfMalNQ6eCXSnG1kYhrR1kaO90CKQmcbC
+R6qYnXk+Yxr2UM7uvGFrgewOKNC+A58dFLFZD0NbfNMU0OQvbsd6A==
=ji9J
-----END PGP SIGNATURE-----

--nextPart1467703.MZbQM7RjYc--