[SM-Grimoire-Bugs] [Bug 10940] get_kernel_version isn't flexible enough

bugzilla-daemon at bugs.sourcemage.org bugzilla-daemon at bugs.sourcemage.org
Mon Oct 16 18:37:16 EDT 2006


------- Additional Comments From iuso at sourcemage.org  2006-10-16 17:37 -------
I think I'm back on track. Please disregard my thoughts about having a query 
for this, it's not a viable idea really.

I'm going to talk about both the kernel version and config functions here, if 
you'll excuse my holisticism. After I write get_kernel_config (which will 
combine get_sorcery_kernel_config and get_running_kernel_config), that and the 
already extant get_kernel_version function will both:

- First check sorcery kernel, and,
- if that fails, use running kernel.

So at that point we'll basically be dealing with the same issue (this bug and 
bug #13071): Letting the user decide which kernel he wants to cast against. 
The spellwriters won't have to worry.

After thinking again about your idea of having something in /etc/sorcery/ I'm 
tilting towards a more bare bones solution. Let's suppose that the 
get_kernel_* functions would first check a variable for a custom kernel 
version before doing the usual sorcery_kernel->running_kernel fallback 
manouvre. The variable could be called OVERRIDE_KERNEL_VERSION.

- To cast against a custom kernel, do: 'OVERRIDE_KERNEL_VERSION=2.6.18-omg 
cast spell'
- If you have the linux spell installed but a different running kernel, and 
want to cast against the running kernel, 
do: 'OVERRIDE_KERNEL_VERSION=`uname -r` cast spell'

That's basically it.

Of course one could then implement whatever magic for setting 
OVERRIDE_KERNEL_VERSION appropriately, like the /sbin/setkernelversion thing. 
Or one could just set it system-wide in a profile.d script. But all in all I 
think the simplified approach I've outlined is how the actual functions should 
work, and wouldn't necessarily require anything else.

What do you think?

Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the SM-Grimoire-Bugs mailing list