Subject: Re: microcode driver for ia-32
To: None <tech-kern@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 08/08/2004 18:21:03
Content-Type: text/plain; charset=us-ascii
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=
> > won't have concurrent, multi-user access to the different devices; they=
> > 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=
> 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=
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=
done. We don't have the usage model of: a user logs into the microcode and=
performs itterative uploads while another user logs into a different CPU's=
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=
> > Higher-end iron can have 16 or 64 heads, and really-high end stuff can=
> > have 512 or 1024 heads. It would be really really messy to have to have=
> > node for each one.
> Hehe, I didn't knew there are systems with 1024 cpus. Indeed, creating on=
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----