lkml.org 
[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Latest microcode data from Intel.
On Fri, 10 Sep 2004, Tigran Aivazian wrote:

> On Fri, 10 Sep 2004, Bill Davidsen wrote:
>
> > Tigran Aivazian wrote:
> > > Hello,
> > >
> > > I have received and tested the latest microcode data file from Intel, The
> > > file is dated 2nd September 2004. You can download it both as standalone
> > > (bzip2-ed) text file and bundled with microcode_ctl utility from the
> > > Download section of the website:
> > >
> > > http://urbanmyth.org/microcode/
> > >
> > > Please let me know if you find any problems with this data file or with
> > > the Linux microcode driver. Thank you.
> >
> > Why are you using /dev/cpu/microcode instead of /dev/cpu/N/microcode for
> > each CPU? Today they are all the same device, but for the future I would
> > think this was an obvious CYA.
>
> I have two questions:
>
> 1. What does "CYA" mean?

Cover Your Ass - or more politely, plan for likely future changes if there
isn't a high cost doing so.
>
> 2. How do you know which device nodes exist on my workstation?

I don't need to... the stat() call will tell me. If a /dev/cpu/0/microcode
exists it is more likely to be the correct loader for CPU0 than some
generic loader. Obviously if the user provides a name use it.
>
> Actually, I am using /dev/cpu/0/microcode as the device node (entry point
> into the microcode driver) because that is what is in the distribution I
> am running (old Red Hat).

That's exactly why I mentioned using the per-cpu device if present. While
having CPUs with different loaders is not a feature today, I wouldn't bet
that will always be true. We know that AMD expects to ship dual core CPUs
in an Opteron form factor. If I have a dual opteron system and replace one
CPU with dual core, will I need a different loader? I have no idea, but
since it's easy to use the per-CPU microcode I would.

>
> The microcode_ctl utility had a hardcoded default "/dev/cpu/microcode" and
> there is no real reason to change it because different distributions
> prefer a different value, so how to decide who is "right"?

The obvious seems to be to see if the per-CPU device is present, and use
it if possible. I can't believe that it would be (by design) less correct
than the generic device.
>
> Also, there is no obvious reason why the future has to be in any way
> different from the present (or the past :)

Your distro and mine already have per-CPU microcode, that's the present.
Lots of people just compile and run, that's the present. It's easy to
check for /dev/cpu/N/micorcode first, then /dev/cpu/microcode, I think
that's the future. I just like having code try a little harder to do the
right thing, Linux should be easy.

--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2011 Jasper Spaans