Messages in this thread | | | Date | Thu, 17 Feb 2000 10:04:21 +1100 | From | Richard Gooch <> | Subject | Re: [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/
| |