| Summary: | [FEAT] Load coretemp kernel module by default | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Scott McMillan <scott.a.mcmillan> |
| Component: | udev | Assignee: | udev-maint |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3 | CC: | harald, jvillalo, nhorman |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-29 17:42:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 767187 | ||
|
Description
Scott McMillan
2011-04-13 21:16:25 UTC
I don't think all people want the coretemp module. Not everyone uses it and as such doesn't need it loaded. I'm also not sure if coretemp supports alternate x86 processors, so adding it by default becomes difficult. If you want to get it to load all the time however, we could add a package to the EPEL repo that just added a udev rule along the following lines: KERNEL=="cpu[0-9]*", ACTION=="add", RUN+="/sbin/modprobe coretemp" perhaps with some additional scripting to validate that its an intel processor being used. would that be sufficient? The key is to have a standard, widely available interface. Otherwise it's impossible to build tools that want to query the temperature. A script that detects whether its a supported processor, and if so, adds the udev rule, is sufficient. ok, well, lets start by re-assigning this to udev, to see if the maintainer wants to just directly add this udev team- is its acceptable to add a rule to the standard udev files, such as the one in comment 2? Looking at the module code it appears to dynamically detect cpu support so we can just blindly modprobe it and have it "do the right thing" No, rules like that make no real sense. Every system has a CPU, and it will always trigger. That's no job for udev rules, or event handlers. Modules are global, and we might have many CPUs, we must not hook into every possible CPU and cause work there; the module can only be loaded one single time. That job can just go to the static module loading in /usr/lib/modules-load.d/, which is simple and efficient. Check 'man modules-load.d'. In case the module depends on a specific CPU feature, that can be discovered, we could be able to auto-load the module with the upcoming CPU modaliases the next kernel release will provide. Just mentioning that here, I have no idea how coretemp works. (In reply to comment #6) > That job can just go to the static module loading in /usr/lib/modules-load.d/, > which is simple and efficient. Check 'man modules-load.d'. That is not available in RHEL-6. RHEL-6 should use /etc/rc.d/rc.local or /etc/rc.modules or a initscript. Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. udev cannot ship this. If you want that drop a shell script in /etc/sysconfig/modules/ , which does the modprobe. |