From owner-acpi-jp@jp.FreeBSD.org Fri Jan  9 05:27:42 2004
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id i08KRgO25125;
	Fri, 9 Jan 2004 05:27:42 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from root.org (root.org [67.118.192.226])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with SMTP/inet id i08KReC25116
	for <acpi-jp@jp.FreeBSD.org>; Fri, 9 Jan 2004 05:27:40 +0900 (JST)
	(envelope-from nate@root.org)
Received: (qmail 36473 invoked by uid 1000); 8 Jan 2004 20:27:35 -0000
From: Nate Lawson <nate@root.org>
To: Hiroyuki Aizu <aizu@navi.org>
cc: acpi-jp@jp.FreeBSD.org
In-Reply-To: <20031228013543.49144197.aizu@navi.org>
Message-ID: <20040108121910.N36424@root.org>
References: <20031223205856.N93778@root.org> <20031225011834.45840753.aizu@navi.org>
 <20031228013543.49144197.aizu@navi.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Thu, 8 Jan 2004 12:27:35 -0800
X-Sequence: acpi-jp 2981
Subject: [acpi-jp 2981] Re: Updated acpi_toshiba driver
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: nate@root.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+031216

On Sun, 28 Dec 2003, Hiroyuki Aizu wrote:
> These trouble caused by range checking of sysctl value.
> It is no need to check arg value at do HCI_GET operation. It return error
> and sysctl operation failed. (It looks like disappear from sysctl tree.)
>
> I try to repair your code. But it makes dirty code like this.
>
> -----------------------------------
> hci_foo()
> {
>     if (op == HCI_GET) {
> 	/* do GET operation */
>     } else if (op == HCI_SET){
> 	/* do SET operation */
>     }
>
>     hci_call()
>
>     if (op == HCI_GET) {
> 	/* do GET operation */
>     } else if (op == HCI_SET){
> 	/* do SET operation */
>     }
> }
> -----------------------------------
> If we use the code like above, it is better separate to set/get function
> that my original code using style.
> (But you dislike that style, I suppose...)

I think the code duplication is small enough that I'll expand it out into
separate get/set functions like you suggest.

> So I take a step forward. I think over again and I sort out these code.
> Please see attached file "acpi_toshiba.c".

I like your table-based approach instead of a huge switch.

> I thkns it is better all Fn-key handling leave it to devd. So I remove the code
> of Hot-key handling from in the kernel.
> (If you want revival the in-kernel handling, you should create tunable value
>  for disable/enable it.)

Are there labels on the keyboard for the Fn-keys?  I really want to keep
in-kernel handling of the keys that are labeled on the keyboard.
As you can see in the version I sent you, I left things like setting the
CPU speed to devd handling since they will obviously not be on the key
labels.  But things like backlight or display output should be handled
in-kernel.  You still get notifies that you can do other useful things
with if you'd like.

My main reason is that devd(8) should be counted on as unreliable.  I'm
not saying it is bad software, I mean it is optional.  No system critical
functions should be dependent on it.  So we will never have critical
thermal events sent out to devd to then turn on fans, for instance.  That
will always be in-kernel.  However, currently power_profile is a shell
script because the worst that happens if devd is not present is that the
system continues running in its AC-line (performance) mode instead of
switching to economy.  That is ok.

For acpi_toshiba, users should still get the functions that are labeled on
the keys without having devd.  However, they can get optional items like
key-based CPU control if they use devd.  This also means that the shell
script can be imported as /usr/share/examples/devd/acpi_toshiba and be
optional.

I hope you understand why I'm doing it this way.

> I am using with devd + /etc/acpi_toshiba shell script that attached this mail.
>
> I'm looking forward to you commit this :-)

Soon.  :)  Thanks for the help.

-Nate
