[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/