Attributes

Attributes

[Smart, James]

What is the preferred method for initializing - and persisting a change - in
a driver's attributes ?

-- James S

Re: Attributes

[Christoph Hellwig]

On Mon, Apr 12, 2004 at 12:43:32PM -0400, Smart, James wrote:
> What is the preferred method for initializing - and persisting a change - in
> a driver's attributes ?

What kind of attributes?

RE: Attributes

[Smart, James]

Think of something as simple as telling a specific instance what link
topology type to initialize as. With the idea that you want to have this
value persist through reboots of the system - and where the boot disk may be
on that instance.  In all the questions I've thrown about - the only
mechanism that appears to also handle boot is to hardcode it in the driver
and recompile the driver for the persistence.

-- James

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@infradead.org]
> Sent: Friday, April 16, 2004 8:03 AM
> To: Smart, James
> Cc: Linux SCSI Reflector
> Subject: Re: Attributes
> 
> 
> On Mon, Apr 12, 2004 at 12:43:32PM -0400, Smart, James wrote:
> > What is the preferred method for initializing - and 
> persisting a change - in
> > a driver's attributes ?
> 
> What kind of attributes?
> 

RE: Attributes

[James Bottomley]

nOn Fri, 2004-04-16 at 08:55, Smart, James wrote:
> Think of something as simple as telling a specific instance what link
> topology type to initialize as. With the idea that you want to have this
> value persist through reboots of the system - and where the boot disk may be
> on that instance.  In all the questions I've thrown about - the only
> mechanism that appears to also handle boot is to hardcode it in the driver
> and recompile the driver for the persistence.

But this isn't a persistent property of the driver, is it?  It's a
property the user wants to set up and have loaded each time.  That can
easily be accommodated via a user daemon and sysfs attributes.

James

RE: Attributes

[Smart, James]

I guess it depends on how you define "persistent property".  Yes - it is a
propery the user wants set up and loaded each time.

I've considered the daemon approach (using sysfs) - but didn't believe it
applied for a value that had to be set at boot time (when the link first
initializes). For boot, the thought is to either compile it in, or perhaps
get it via a module parameter assuming module.conf get copied into the
inital ram disk.

This brings up another question...  assuming a driver gets into the kernel
tree, but it has an associated user-space entity like this daemon. How does
one get the user-space elements onto the different distributions in concert
with the kernel ?  (other than lobbying each distribution individually ?)

-- James


> -----Original Message-----
> From: James Bottomley [mailto:James.Bottomley@SteelEye.com]
> Sent: Friday, April 16, 2004 10:26 AM
> To: Smart, James
> Cc: 'Christoph Hellwig'; Linux SCSI Reflector
> Subject: RE: Attributes
> 
> 
> nOn Fri, 2004-04-16 at 08:55, Smart, James wrote:
> > Think of something as simple as telling a specific instance 
> what link
> > topology type to initialize as. With the idea that you want 
> to have this
> > value persist through reboots of the system - and where the 
> boot disk may be
> > on that instance.  In all the questions I've thrown about - the only
> > mechanism that appears to also handle boot is to hardcode 
> it in the driver
> > and recompile the driver for the persistence.
> 
> But this isn't a persistent property of the driver, is it?  It's a
> property the user wants to set up and have loaded each time.  That can
> easily be accommodated via a user daemon and sysfs attributes.
> 
> James
> 
> 

RE: Attributes

[James Bottomley]

On Fri, 2004-04-16 at 10:03, Smart, James wrote:
> I've considered the daemon approach (using sysfs) - but didn't believe it
> applied for a value that had to be set at boot time (when the link first
> initializes). For boot, the thought is to either compile it in, or perhaps
> get it via a module parameter assuming module.conf get copied into the
> inital ram disk.

Not at all.  All that happens is that you have to run the daemon before
using the devices.  So you'd need an initramfs/initrd daemon but *only*
if your root device is on a fibre whose topology you want to control.

> This brings up another question...  assuming a driver gets into the kernel
> tree, but it has an associated user-space entity like this daemon. How does
> one get the user-space elements onto the different distributions in concert
> with the kernel ?  (other than lobbying each distribution individually ?)

One publishes the user space entries separately.  The distributions
necessarily pick them up if they want the driver to work correctly.

James