I read elsewhere on the web that kernel-parameters.txt is not particularly helpful because it is out of date.
Trying to find out more about acpi_osi, I note it was suggested to try this:
oldcpu@core-i7:/usr/src/linux-2.6.34.7-0.7/drivers/acpi> grep -rw __setup /usr/src/linux-2.6.34.7-0.7/drivers/acpi/*.*
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c:__setup("acpi_no_initrd_override", acpi_no_initrd_override_setup);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c:__setup("acpi_no_initramfs_override", acpi_no_initramfs_override_setup);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c:__setup("acpi_os_name=", acpi_os_name_setup);
**/usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c**:__setup("acpi_osi=", acpi_osi_setup);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c:__setup("acpi_serialize", acpi_serialize_setup);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c:__setup("acpi_wake_gpes_always_on", acpi_wake_gpes_always_on_setup);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c:__setup("acpi_enforce_resources=", acpi_enforce_resources_setup);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/pci_link.c:__setup("acpi_irq_isa=", acpi_irq_isa);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/pci_link.c:__setup("acpi_irq_pci=", acpi_irq_pci);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/pci_link.c:__setup("acpi_irq_nobalance", acpi_irq_nobalance_set);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/pci_link.c:__setup("acpi_irq_balance", acpi_irq_balance_set);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/video_detect.c:__setup("acpi_backlight=", acpi_backlight);
/usr/src/linux-2.6.34.7-0.7/drivers/acpi/video_detect.c:__setup("acpi_display_output=", acpi_display_output);
Which suggests that the information on acpi_osi_setup is located in the file acpi_osi and then further suggests for one to look inside /usr/src/linux-2.6.34.7-0.7/drivers/acpi/osl.c and note:
/*
* The story of _OSI(Linux)
*
* From pre-history through Linux-2.6.22,
* Linux responded TRUE upon a BIOS OSI(Linux) query.
*
* Unfortunately, reference BIOS writers got wind of this
* and put OSI(Linux) in their example code, quickly exposing
* this string as ill-conceived and opening the door to
* an un-bounded number of BIOS incompatibilities.
*
* For example, OSI(Linux) was used on resume to re-POST a
* video card on one system, because Linux at that time
* could not do a speedy restore in its native driver.
* But then upon gaining quick native restore capability,
* Linux has no way to tell the BIOS to skip the time-consuming
* POST -- putting Linux at a permanent performance disadvantage.
* On another system, the BIOS writer used OSI(Linux)
* to infer native OS support for IPMI! On other systems,
* OSI(Linux) simply got in the way of Linux claiming to
* be compatible with other operating systems, exposing
* BIOS issues such as skipped device initialization.
*
* So "Linux" turned out to be a really poor chose of
* OSI string, and from Linux-2.6.23 onward we respond FALSE.
*
* BIOS writers should NOT query _OSI(Linux) on future systems.
* Linux will complain on the console when it sees it, and return FALSE.
* To get Linux to return TRUE for your system will require
* a kernel source update to add a DMI entry,
* or boot with "acpi_osi=Linux"
*/
and note:
/*
* Modify the list of "OS Interfaces" reported to BIOS via _OSI
*
* empty string disables _OSI
* string starting with '!' disables that string
* otherwise string is added to list, augmenting built-in strings
*/
int __init acpi_osi_setup(char *str)
{
if (str == NULL || *str == '\0') {
printk(KERN_INFO PREFIX "_OSI method disabled
");
acpi_gbl_create_osi_method = FALSE;
} else if (!strcmp("!Linux", str)) {
acpi_cmdline_osi_linux(0); /* !enable */
} else if (*str == '!') {
if (acpi_osi_invalidate(++str) == AE_OK)
printk(KERN_INFO PREFIX "Deleted _OSI(%s)
", str);
} else if (!strcmp("Linux", str)) {
acpi_cmdline_osi_linux(1); /* enable */
} else if (*osi_additional_string == '\0') {
strncpy(osi_additional_string, str, OSI_STRING_LENGTH_MAX);
printk(KERN_INFO PREFIX "Added _OSI(%s)
", str);
}
return 1;
}
__setup("acpi_osi=", acpi_osi_setup);
which I have read means one can define any routine which accepts a character string value for a kernel parameter, then tie the parameter name to that routine. The routine is then free to parse/interpret that value however it pleases.
However my suspicion is that those words are more for those who compile a kernel, than for those of us who simply use the kernel. 
… Ergo, I do not know to what extent the SuSE-GmbH kernel packagers still package the acpi_osi option ?