lkml.org 
[lkml]   [2000]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch-2.3.46-p2] P6 microcode update support
Tigran Aivazian writes:
> > > Ok, I will come back with implementation when it is ready.
> > >
> >
> > I *really* think this is a mistake for reasons previously explained.
> > This should be /dev/microcode or /dev/cpu/microcode
>
> well, let's agree on this. I agree with Linus that the latest version of
> /dev/microcode patch is ok, so if he accepts it as is (i.e. a char misc
> driver on minor=184) it will be fine.
>
> I also can save a minor number and implement the /proc/driver/microcode.
>
> I cannot (right now) implement a devfs-aware version
> /dev/cpu/microcode because I have not looked at Richard's devfs
> stuff yet.

http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html

> Of Linus' /proc/driver vs /dev argument I understood b) but not a) or
> c). Namely,
>
> a) there is still userspace setup of using ioct on a proc file

What he means is that the administrator has to create a device node to
make it accessible. With a virtual device node in procfs or devfs this
isn't needed.

> c) whether kernel has update support or not is determined by whether
> the minor=184 is accessible (perhaps by loading a driver) or not.
> /proc does not make things much easier.

It's much friendlier to the sysadmin or script writer to list the
directory or test for the file than to do a speculative open. I don't
know of a standard programme (say part of shell utils) that does this.

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

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

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.087 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site