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