>> This was the solution I was thinking about. It seems to me that
>> the drivers should be responsible for saving the hardware
>> persistance. Forgetting the mixer state for a second, saving off
>> hardware register state is a requirement for some power
>> managment schemes.
> I'm not too bothered who's "responsible" for it - as long as
> it's actually possible to do it. I'm happy to handle it in
> user-space as much as possible, but we need a small amount of
> modification to the kernel drivers to make that possible - that
> is; a way of passing the required mixer levels to the driver
> when it starts up (or postponing the mixer init until it's given
> the levels by an ioctl), and a way of obtaining the final
> settings from the driver before it's unloaded.
One thought would be to have a file that's loaded by the kernel as
part of its start-up, which contains the relevant settings as last
saved. Something like...
1. Have each driver mark the relevant settings as "savable".
2. Whenever one of the settings marked as "savable" is changed,
modify the relevant file to contain the revised setting.
3. If the SAVEFILE flag in the kernel's flag word is set, have
the kernel load this file early in its start-up, and treat
each line therein that was not already on the kernel's list
of parameters as an additional kernel parameter to be added
to its command line.
Note that at the moment, the kernel's flag word only has one bit
defined, which determines whether the root partition is mounted
read-only or read-write. Since it is defined as a 16-bit value, there
are 15 unused flags there, so there would be little problem adding an
extra flag in there.
The only restriction I can see to this method is that the relevant
disk subsystem would need to be initialised without benefit of this
file, to enable the kernel to locate the file in question.
Note also that I've said that the file would be updated as the
settings were changed. This is to minimise the effects of system
crashes, which could otherwise cause updates to get lost.
>> This brings up another point. I want to save state as a means
>> of getting away from passing command line parameters. This is
>> a scary prospect for the new Linux user.
> I meant this to be automated - the levels recorded from the
> previous incarnation of the driver should be passed to the new
> incarnation without the user ever seeing them.
The above would automate it as much as is possible.
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
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/