--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 06, 2004 at 06:52:30PM +0100, phlox wrote:
> On 2004.08.06 09:38:07 +0000, Bill Studenmund wrote:
> > I'd say just one device will be fine. The important thing is that you=
=20
> > won't have concurrent, multi-user access to the different devices; they=
=20
> > aren't tty's that folks are logged-onto. Also, once you've done the=20
> > update, you don't need the devices anymore.
> Well, I need them since the microcode update isn't permanent. A reset wil=
l make
> it go away.

That's fine. You can upload microcode each boot, with an rc.d script.

My point was more that this device will have very different usage=20
semantics from other devices, like say tty or lpt or wscons devices. With=
=20
those other devices, it is quite reasonable and common to have multiple,=20
simultaneous, and distinctly different access to the different devices.=20
Like one printer can print general text, another color documents, and a=20
third cut checks. I often have five different wscons consoles going,=20
logged into different things. This different access is on-going. Thus=20
different devices make a lot of sense, and are needed for (among=20
other things) ownership.

The microcode interface just needs to upload microcode once and then we're=
=20
done. We don't have the usage model of: a user logs into the microcode and=
=20
performs itterative uploads while another user logs into a different CPU's=
=20
microcode to play with it. :-) Root should be the only user to upload=20
microcode, and we uploading it will be an uncommon occurence.

> > Further, there are systems out there with much more than 4 CPUs on them=
.=20
> > Higher-end iron can have 16 or 64 heads, and really-high end stuff can=
=20
> > have 512 or 1024 heads. It would be really really messy to have to have=
 a=20
> > node for each one.
> Hehe, I didn't knew there are systems with 1024 cpus. Indeed, creating on=
ly a
> device is the right way to go.

I'm not sure if it's supported for x86, but other CPU families have done=20
it, and I'd like us to come up with a solution that can scale to that=20
scenario.

Take care,

Bill

--lrZ03NoBR/3+SXJZ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBFtF/Wz+3JHUci9cRApiPAJsFbjPd3CFLDhhMi6D05KkgwIuHdwCeNb2u
82n6Amr1JwawO5y0fEOaHHo=
=EzDt
-----END PGP SIGNATURE-----

--lrZ03NoBR/3+SXJZ--