Sorry that it took so long to reply, our network is currently out, and I
don't know when we will be back online.
> > 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.
Well, this is not Windows. You cannot use the BIOS for more than loading
the kernel image.
> Yes, with the thin driver model, device re-initialization is going to
> be necessary on platforms without legacy initialization.
Nope, on all machines. Legacy init does not care about ACPI registers. If
you go to sleep without initializing them, *Kaboom*
> [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.
Okay, but we also need to precompile all the code that will be necessary
to get the devices back up that are required for the daemon to be
executed.
> [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.
Yes, but this is about the possible damage. I have the last four versions
of each file on tape, so I don't care too much if someone does a "rm -rf
/", I just need to get my backup floppy and be up and running again within
four hours. If you turn off my CPU fan, the damage is much greater.
> #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.
I need something more than that to start developing code. I don't want to
throw it all away because there is no solution to the problems. Also, I'd
like to have #3 solved.
> You are going to need a much more convincing argument
> to get that much code into the kernel initially.
Aren't security, stability and simplicity enough? :-)
> 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?
Because it is difficult to move the code you are suggesting into the
kernel. I can live with a solution like the one you suggest, but only if
it has no important disadvantages. I still see those three. If you manage
to convince me that these are no issues, or that I can also live with that
and put that on a server safely (We have a server room without cooling
here), you can count me in.
Simon
PGP public key available from ftp://phobos.fs.tum.de/pub/pgp/geier.asc
Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1
-
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/