Messages in this thread | | | Date | Mon, 20 Sep 1999 16:37:31 -0700 (PDT) | From | Andy Henroid <> | Subject | Re: [PATCH] generic ACPI support |
| |
-- Simon Richter <geier@phobos.fs.tum.de> wrote: > > I think that the "thin driver" model has some > important drawbacks:
[1. device enumeration/initialization]
This will not be an issue until hardware that depends on ACPI for initialization appears. That's going to be a while and, even then, boot devices will always be initialized by the system so the OS can be loaded.
Yes, with the thin driver model, device re-initialization is going to be necessary on platforms without legacy initialization. And yes, that's going to be complicated but I think it is definitely workable.
[2. device sleep/wake]
Right, we can't rely on user-space for turning storage devices on and off. What we can do is pre-run the AML in user-space and upload the I/O access sequence to the kernel for execution.
[3. security]
It's just as easy to install a new kernel or kernel module as it is to replace a system daemon. If someone has root access you are vulnerable with either model.
> This is why I favor the static solution, even if it > bloats the kernel and is hard to debug.
#1 and #2 are definitely important issues but I think there are solutions to both while keeping the bulk of ACPI code in user-space.
You are going to need a much more convincing argument to get that much code into the kernel initially. Why don't we go the thin way and as specific issues arise or new hardware appears, then push more of the code into the kernel?
Thanks, Andy
__________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |