I've been looking at everything I can find, asked a few questions, and don't
have an answer to the following issue.
I have a driver that wants to export attributes per instance. I'd like the
ability for the user to modify an attribute dynamically (sysfs works well) -
but I'd like the new value to be persistent the next time the driver
unloads/loads or the system reboots. I don't want to have to update
constants in source and recompile the driver. I'm looking for something
similar (cringe!) to the MS registry. Is there a facility available to
kernel objects to allow for persistent attributes to be set/retrieved? If
not, any recommendations on how to implement this ?
-- james
Yes - I was well aware of this, and considered it an "automation" of the
user funciton.
Unfortunately, this won't work, as it doesn't address the case where the
driver is part of the boot process (e.g. it's the hba used to reach the boot
disk). I'm looking for something that addresses this too..
-- James
> -----Original Message-----
> From: Richard B. Johnson [mailto:[email protected]]
> Sent: Thursday, April 15, 2004 2:07 PM
> To: Smart, James
> Cc: '[email protected]'
> Subject: Re: persistence of kernel object attribute ??
>
>
> On Thu, 15 Apr 2004, Smart, James wrote:
>
> >
> > I've been looking at everything I can find, asked a few
> questions, and don't
> > have an answer to the following issue.
> >
> > I have a driver that wants to export attributes per
> instance. I'd like the
> > ability for the user to modify an attribute dynamically
> (sysfs works well) -
> > but I'd like the new value to be persistent the next time the driver
> > unloads/loads or the system reboots. I don't want to have to update
> > constants in source and recompile the driver. I'm looking
> for something
> > similar (cringe!) to the MS registry. Is there a facility
> available to
> > kernel objects to allow for persistent attributes to be
> set/retrieved? If
> > not, any recommendations on how to implement this ?
> >
> > -- james
> >
>
> Make a program that executes upon startup, using the Sys-V startup
> convention. That program interfaces with your driver using a standard
> ioctl() call. It can send or receive anything it wants, which it can
> get or put to any accessible file-system.
>
> FYI this is the standard Unix/Linux way. You'd be surprised the
> large number of users who haven't got a clue about how Unix starts
> up. They vaguely remember something about "init" and that's it.
> To refresh your memory, look in /etc/rc.d and the sub-directories
> for each run-level. Believe me, you don't want or need a "registry".
> Just put a link to your startup-script in there.
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.24 on an i686 machine (5596.77 BogoMips).
> Note 96.31% of all statistics are fiction.
>
>
On Thu, 15 Apr 2004, Smart, James wrote:
> Yes - I was well aware of this, and considered it an "automation" of the
> user funciton.
>
> Unfortunately, this won't work, as it doesn't address the case where the
> driver is part of the boot process (e.g. it's the hba used to reach the boot
> disk). I'm looking for something that addresses this too..
>
In that case, the "registry" won't work either. If you can't
access the file-system that contains the "registry" (it's just
a corrupt file), to get the bits necessary to turn on your
controller, then you need to use a serial EEPROM or some such
as is done all the while.
Over and over again, I hear people who think that you should
be able to open a file from within the code that opens the
file (the kernel). Turns out, you now can. You can create
a task called a "kernel thread". Since it has a context, it
can open a file and read from it (not using any user-mode
interface). But this won't help you either because the
file won't exist until you configure your controller
and it gets mounted.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (5596.77 BogoMips).
Note 96.31% of all statistics are fiction.
On Thu, 15 Apr 2004, Smart, James wrote:
>
> I've been looking at everything I can find, asked a few questions, and don't
> have an answer to the following issue.
>
> I have a driver that wants to export attributes per instance. I'd like the
> ability for the user to modify an attribute dynamically (sysfs works well) -
> but I'd like the new value to be persistent the next time the driver
> unloads/loads or the system reboots. I don't want to have to update
> constants in source and recompile the driver. I'm looking for something
> similar (cringe!) to the MS registry. Is there a facility available to
> kernel objects to allow for persistent attributes to be set/retrieved? If
> not, any recommendations on how to implement this ?
>
> -- james
>
Make a program that executes upon startup, using the Sys-V startup
convention. That program interfaces with your driver using a standard
ioctl() call. It can send or receive anything it wants, which it can
get or put to any accessible file-system.
FYI this is the standard Unix/Linux way. You'd be surprised the
large number of users who haven't got a clue about how Unix starts
up. They vaguely remember something about "init" and that's it.
To refresh your memory, look in /etc/rc.d and the sub-directories
for each run-level. Believe me, you don't want or need a "registry".
Just put a link to your startup-script in there.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.24 on an i686 machine (5596.77 BogoMips).
Note 96.31% of all statistics are fiction.