Message-ID: <4110.10.10.10.24.1110915247.squirrel@linux1>
In-Reply-To: <20050315190847.GA1870@isilmar.linta.de>
References: <20050315170834.GA25475@kroah.com>
    <20050315190847.GA1870@isilmar.linta.de>
Date: Tue, 15 Mar 2005 14:34:07 -0500 (EST)
Subject: Re: [RFC] Changes to the driver model class code.
From: "Sean" <seanlkml@sympatico.ca>
To: "Dominik Brodowski" <linux@dominikbrodowski.net>
Cc: "Greg KH" <greg@kroah.com>, linux-kernel@vger.kernel.org,
       "Kay Sievers" <kay.sievers@vrfy.org>
User-Agent: SquirrelMail/1.4.4-2
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 977
Lines: 22

On Tue, March 15, 2005 2:08 pm, Dominik Brodowski said:

> For example, temperature sensors could be exported
> using /sys/class/temp_sensors/... -- then userspace wouldn't need to know
> whether the temperature was determined using an ACPI BIOS call or by
> accessing an i2c device. Such "abstractions", and other kernel code whcih
> uses these "abstractions" (a.k.a. class interfaces) are a great feature
> to have, and one too less used by now.

That really sounds like a job for user space, why complicate the kernel?  
A simple user space library could handle returning temperatures without
the caller knowing from where the value was obtained.   Isn't this the
exact type of thing that just bloats a kernel needlessly?

Sean


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/