[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-power
Subject:    Re: [linux-power]Re: System-wide device power management
From:       Mike Smith <msmith () FreeBSD ! ORG>
Date:       2001-04-05 19:32:35
[Download RAW message or body]

> [This is the last time I'm copying the acpi list. If you're interested in PM
> and haven't joined linux-power, I suggest you do so.]

[I'm not going to join this list, as I get enough mail already; please
 keep me copied if you think that my input may be useful.]

> Funny, I was just looking at kobj.h and bus.h yesterday. ;-)

8)

> We need to watch out for over-engineering. I'm not saying kobj is, but I
> think we will need to justify why each abstraction we make is worthwhile so
> Linus will go along. (And, it's probably a good idea anyways.)

Perhaps.  It would not be surprising to hear that I consider Linus' 
attitude to "overengineering" to be somewhat shortsighted.  Certainly, 
you're going to get shouted down for any sort of engineered solution, and 
adapting kobj wholesale would probably fall into that category.

> I think we need to answer the following questions:
> 1) What steps did FreeBSD take in moving towards their current model?

We (I use the term loosely 8) designed and implemented the new model 
(mostly dfr) and then implemented a set of backwards-compatible shims for 
older drivers (mostly peter).

This was fairly easy because we were only changing the layering 
interface; the driver aggregation and location technologies haven't 
really changed.

> 2) What were the benefits and drawbacks of these intermediate steps?

The benefit was that we didn't have to touch any drivers initially; the 
shims meant that we could continue to use the existing driver codebase.  
That's also proven to be a major drawback; with the shims in place, 
there's less incentive for people to convert their drivers (and as the
shims slowly get removed, driver developers react with surprise and 
irritation).

> 3) How much work was all of this and how long did it take?

You would need to ask Doug (dfr).  I seem to recall him saying that the 
actual implementation took a couple of weeks; the issues had been talked
around for years though.  Converting a given driver is pretty trivial;
the semantics of the interface haven't changed a whole lot.

> 4) Can Linux also start by leveraging a VFS-like design?
> 5) Can we borrow ideas from other object-based driver models, such as
> Windows or BeOS?

I can't really answer these.

> So, I'm going to continue looking at the current FreeBSD model for ideas,
> but any historical data or documents on its evolution would also be great -
> do you know of any?

The CVS repository is probably the best place to start.  Beyond that, you 
might want to check the -hackers and -current mailing list archives.

> PS you guys got sleep working yet? ;-)

I have been so busy work-wise that I'm at least two source drops behind. 
(and the latest test version *still* doesn't work on my i7500, and I bet 
that now you're doing mutexes again, it's not going to work on the STL2).

So I guess that means "no" 8(.

Anyway, I hope some of this is useful.

Regards,
Mike

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E

[prev in list] [next in list] [prev in thread] [next in thread]