What to use for OS-specific module namespaces?

ruby-talk
1

You’re going to write to the /proc filesystem?!

Yeah; a number of files in /proc do things when you write to them;
notably the ACPI stuff that I’m interested in. To change your speedstep
state, for instance, you write a “1” or “0” to
/proc/acpi/processor/CPU0/performance; to go into sleep mode, write a
“1” (for S1 state) to /proc/acpi/sleep. There are other things too,
like
I think you need to write a 1 to start IP forwarding and khttpd and a
few other things.

Ah, interesting. Your documenation then should probably start with
“THIS MODULE REQUIRES ROOT PERMISSIONS TO THE /proc FILESYSTEM!!!”. :stuck_out_tongue_winking_eye:

But yeah, I know that /proc is significantly different across OSs; I
prefer to think of it as Linux being right and the rest being broken,
but that’s not a very pragmatic approach. So, I’m going to try the
namespace shorthand trick for now.

It has the advantage that any ol’ program can read it, true. The
drawback is that you can’t seem to trust the folks at “Linux, Inc” to
keep the format the same. Mike Hall has already mentioned to me that
some stuff is out of order in my Sys::ProcTable module between 2.2 and
2.4 on Linux. Puke. A built-in library eliminates this hazard (I’m
only going to deal with 2.4, btw). A C library is probably going to be
faster as well. Six one way, half a dozen the other, I guess. But,
this is getting OT…

I’d prefer to avoid a C extension library if possible; Linux lets me do
this by reading all the data from /proc. In fact, I’m not sure if there
is any other way to get a lot of the hardware information. How do other
UNIXes let you get things like processor model/speed, memory
information, etc?

There might be. I find going to www.deja.com and searching on all of
the “comp” hierarchy a very useful thing to do. :slight_smile: I just scoured CPAN
a bit to see what was already out there - not a heck of a lot, but a
couple cpu modules. Dunno how good they are, though. I also noticed
the Solaris::Procfs module, which I had seen before but forgotten about.
That might be useful as a starting point for cross-platform support (?).

I’d like to put the model under the Sys:: namespace for consistency; if
you think it’s a good idea; then I’m left with the question of what to
call it again. :slight_smile: Sys::Hardware? Sys::Info seems too generic a name
(since Uptime, ProcTable, and Uname are both “Info” too).

Sys::ACPI seems appropriate. If you’re interested, I could investigate
Solaris support once you’ve got your api fleshed out.

Regards,

Dan

···

-----Original Message-----
From: Joe Wreschnig piman@sacredchao.net

2

Well, the problem is that while some parts of ACPI are solely ACPI (like
AC adapter information), others (like processor SpeedStep or throttling)
are closely tied to the non-ACPI parts of the processor. I guess I can
just remove the Info namespace altogether and have Sys::CPU, Sys::ACPI,
etc.

(for a sample of the API right now -

SysInfo::Linux::CPU[0].ghz => 1.59
SysInfo::Linux::CPU[0].state.clock => 1600 # Main power state
SysInfo::Linux::CPU[0].state[1].clock => 1200 # Lower-power state

Use low-power state for all CPUs

SysInfo::Linux::CPU.each { |c| c.state = c.state[1] }
SysInfo::Linux::CPU[0].state.clock => 1200

If ACPI is not available, things like SysInfo::Linux::CPU[0]::state
never get defined, but SysInfo::Linux::CPU[0].ghz will still work; only
the SysInfo::Linux::ACPI::exists? function will be available otherwise.)

···

On Mon, 2002-07-08 at 12:29, Mr. Sunblade wrote:

I’d like to put the model under the Sys:: namespace for consistency; if
you think it’s a good idea; then I’m left with the question of what to
call it again. :slight_smile: Sys::Hardware? Sys::Info seems too generic a name
(since Uptime, ProcTable, and Uname are both “Info” too).

Sys::ACPI seems appropriate. If you’re interested, I could investigate
Solaris support once you’ve got your api fleshed out.

–