On 2008-Jun-06 02:09:27 +0400, Stanislav Sedov <stas_at_freebsd.org> wrote: >> 2) in cpuctl_modevent(): perhaps it's better to return ENOMEM instead of >> ENOSYS if malloc() fails and ENXIO instead of ENOSYS if MSR functionality is >> not present > >I fully agree on ENOMEM (thanks for noticing that), while I think that >returning ENOSYS for MSR-less systems is more correct, as it states that >required functionality isn't implemented for this hardware. ENOSYS generally means "system call not implemented". You need a response implying that the requested operation isn't supported on the hardware. IMHO, ENODEV comes closest to that. I also agree with phk_at_ that serious thought needs to be given to the foot-shooting capability offered by this patch before it is implemented. Maybe add a sysctl to enable the write (at least) functionality - eg hw.cpuctl.wrmsr_enable and hw.cpuctl.update_enable (both defaulting to disabled). This at least adds a safety catch. I'm not sure if RDMSR is dangerous - if so, possibly there should be an enable for it as well. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:31 UTC