RE: [ACPI] new acpi patches impressions

[Patrick M. <mo...@os...>]

On Thu, 7 Feb 2002, Diefenbaugh, Paul S wrote:

> Pat:
> 
> > And, concerning this aspect, you are one of many peers that will 
> > consume some common code. And, you have developed a solution. My 
> > only question was, if you have a solution, how well, in your mind, 
> > will it potentially fit with your other peers? 
> 
> Support for ACPI and non-ACPI, as well as IA32 and IA64, have been in our
> thoughts throughout this process.  This is where the "view-by-type" paradigm
> shines: standardize on a platform-agnostic set of standard device classes
> (types) -- and a set of standard (but extensible) interface definitions for
> each type -- and you're in business.

Ok, I'm punting on this question until you guys actually release the code. 
Then, I'll try to ask again.

> We need to get a "view-by-type" solution into the new driver model (thus
> getting rid of /proc/acpi) -- and associate entries (e.g. via symbolic
> links) with the existing "view-by-connection" hierarchy.  From there it's
> just a matter of defining the 'right' interfaces for each device class (e.g.
> processors, thermal zones, batteries, etc.) -- something along the line of
> your standardized driverfs entries.  Policy builds upon these interfaces;
> and then GUI on top of that.

What you're referring to has many names and many faces. My current 
vernacular refers to it as 'logical device representation' or the 'device 
naming problem'. Though, I've been known to call it 'device class support' 
or 'devfs-like support'. It's a problem that has many, many implications; 
and many, many facets. 

I agree that something is needed. I think everyone agrees on that. It will 
cause a lot of arguments and broken hearts in trying to figure the best 
solution. 

I've experimented with a few solutions, and it has been a topic of several 
conversations in the last couple of weeks. Conceptually, things are 
condensing, but it's still not..quite..there..

So, let me pose this question to you: what's wrong with creating the 
symlinks in userspace? In theory, you should be able to logically refer to 
a device by any name, like you can currently with network device. 

It should be userspace policy to determine or save what you want to call 
the device. 

Say you have two batteries in your system, one has 5x the capacity of the 
other. You want an applet on your desktop that displays the status of only 
the larger one, since that's the only oen that matters. You fire up the 
battery applet thingy-ma-bob and want to point it at the large one. How 
are you going to know which is which?

You could get on the command line, and go to /dev/batteries and see:

$ ls
0/	1/

cd to each, root around in the text files and try and figure out which one 
is larger. 

(and remember that each of those are merely symlinks to 
$driverfs/root/sys/battery0 (or whatever))

Or...on one rainy day when you're setting up your linux laptop and feeling 
adventurous, you could find the config file for device names (or the GUI 
applet that manages it), and set the logical name of 
$driverfs/root/sys/battery0 to be "big_battery" so you would always know 
every time which battery was which. 

That's flexibility. You can't (easily) do that in kernel space. And, it's 
not just some silly example. You can extend that to disks, video cards, 
whatever. Anyway, it's just food for thought at this point...

> We prototyped our take on a global "view-by-type" paradigm in our LDM
> proposal, in case you're interested in the details.

Sure, send it along.

	-pat