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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:17 EST