Messages in this thread | | | Date | Tue, 22 Feb 2000 22:58:27 +1100 | From | Richard Gooch <> | Subject | Re: [patch-2.3.47] /proc/driver/microcode -> /dev/cpu/microcode |
| |
Tigran Aivazian writes: > Hi Richard, > > Before I send this patch to Linus, perhaps you could cast your armed eye > to see if I missed any of required devfs magic in the microcode driver. I > only tested it in devfs=nomount mode - works fine (I looked at mtrr.c to > learn how to use the new interface). > > http://www.ocston.org/~tigran/patches/microcode/mc-2.3.47.patch
Looks fine (I looked at the URL version). I couldn't have done it better myself.
> Btw, when you devfs_register() /dev/cpu/mtrr you don't check for > failure return - maybe you should?
In theory, but it doesn't matter because:
- /dev/cpu/mtrr is created during kernel bootup, hence there should be no problem with insufficient memory (if there is, there will be other problems anyway)
- even if the user-space interface is missing, you still want to go through the process of making MTRRs for all CPUs the same.
> Also, perhaps we should move /proc/rtc to /dev/cpu/rtc as well? I > know that /dev/rtc is already is /dev/misc/rtc but that is the > actual driver whilst the human readable regular file could happily > live in /dev/cpu/rtc (although it is not strictly "on cpu" but only > a couple of inches away :)
I don't have /proc/rtc on my machine, but I do have /dev/misc/rtc, so I don't know where /proc/rtc comes from.
I think we should be strict with the new devfs namespace. If it's not actually part of the CPU, it doesn't belong in /dev/cpu. If we're not strict, we end up with the same ad-hockery as /proc.
I'll (reluctantly) be the gatekeeper for devfs names if it means the namespace is kept sane.
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/
| |