Re: [PATCH] drop some attibutes from the FC transport class

2005-01-20 Thread Greg KH
On Wed, Jan 19, 2005 at 11:12:00PM -0600, Matt Domsch wrote:
 On Wed, Jan 19, 2005 at 03:42:19PM -0800, Greg KH wrote:
  Here it was against 2.6.9.  Odds are it doesn't apply anymore due to
  some recent changes in this area.  If anyone wants to take it and fix it
  up, please do so.
  
  Note, this patch needs the evil strdup() function to work properly.
  That's one of the main reasons I decided to not submit it to the main
  kernel tree...
 
 How would you feel if instead, we just didn't drop the .modinfo
 section?  That would eliminate the need to copy the strings, and then
 the field##_get_function would just use the string from the .modinfo
 section directly?

That makes sense to me, but you might want to ask Rusty about it, as
it's his code.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH] drop some attibutes from the FC transport class

2005-01-19 Thread James . Smart
True. The only thing that made them FC-ish is that they were
mandated by HBAAPI.  The only other desire was to place all
hbaapi-related data in a single place so users/applications don't
have to trapse through the multiple directories in the class and
device trees.

I'll ping Greg on adding them to the common driver model code.

As for the copyright notices - I'll add them. Sorry, my lack of
procedure on kernel additions.  Just trying to be a good citizen.

-- James


 I think the hardware_version, firmware_version, rom_version and
 driver_version don't belong into the FC transport class, there's
 nothign specific to FC or even SCSI specific in them.
 
 If you want these attributes talk to Greg about fiding a place in
 the common driver model code for them.
 
 p.s. I was surprised to find no Emulex copyright notices in the FC
 transport implementation fields, I suspect you should add them.
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drop some attibutes from the FC transport class

2005-01-19 Thread Greg KH
On Wed, Jan 19, 2005 at 06:13:57PM +0100, Christoph Hellwig wrote:
 I think the hardware_version, firmware_version, rom_version and
 driver_version don't belong into the FC transport class, there's
 nothign specific to FC or even SCSI specific in them.

Then put them in the individual driver (not the driver_version one
though, that belongs as a MODULE_VERSION() paramater).

 If you want these attributes talk to Greg about fiding a place in
 the common driver model code for them.

No, they don't belong there either, sorry :)

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drop some attibutes from the FC transport class

2005-01-19 Thread Brian King
Greg KH wrote:
On Wed, Jan 19, 2005 at 06:13:57PM +0100, Christoph Hellwig wrote:
I think the hardware_version, firmware_version, rom_version and
driver_version don't belong into the FC transport class, there's
nothign specific to FC or even SCSI specific in them.

Then put them in the individual driver (not the driver_version one
though, that belongs as a MODULE_VERSION() paramater).

If you want these attributes talk to Greg about fiding a place in
the common driver model code for them.

No, they don't belong there either, sorry :)
How about at an attribute on the pci object? I currently have a driver 
private firmware version in the ipr driver as a scsi_host class 
attribute. Not sure how many other drivers will end up doing similar. 
Might be nice to have a common way to export this information to 
userspace. Or we can always wait for more users before we do something 
like this...

-Brian
--
Brian King
eServer Storage I/O
IBM Linux Technology Center
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drop some attibutes from the FC transport class

2005-01-19 Thread Greg KH
On Wed, Jan 19, 2005 at 12:38:31PM -0600, Brian King wrote:
 Greg KH wrote:
 On Wed, Jan 19, 2005 at 06:13:57PM +0100, Christoph Hellwig wrote:
 
 I think the hardware_version, firmware_version, rom_version and
 driver_version don't belong into the FC transport class, there's
 nothign specific to FC or even SCSI specific in them.
 
 
 Then put them in the individual driver (not the driver_version one
 though, that belongs as a MODULE_VERSION() paramater).
 
 
 If you want these attributes talk to Greg about fiding a place in
 the common driver model code for them.
 
 
 No, they don't belong there either, sorry :)
 
 How about at an attribute on the pci object?

It is a pci specific attribute?  If so, I'll add it to the pci core.
Otherwise you are free to add it yourself to the pci device in your pci
driver to that location.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drop some attibutes from the FC transport class

2005-01-19 Thread Mike Anderson
Greg KH [EMAIL PROTECTED] wrote:
 On Wed, Jan 19, 2005 at 06:13:57PM +0100, Christoph Hellwig wrote:
  I think the hardware_version, firmware_version, rom_version and
  driver_version don't belong into the FC transport class, there's
  nothign specific to FC or even SCSI specific in them.
 
 Then put them in the individual driver (not the driver_version one
 though, that belongs as a MODULE_VERSION() paramater).

Are there plans to export MODULE_VERSION info in /sys/module/*/ ? I
believe the intent was to try and use libsysfs to access these attributes
/ info.

-andmike
--
Michael Anderson
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drop some attibutes from the FC transport class

2005-01-19 Thread Greg KH
On Wed, Jan 19, 2005 at 11:03:50PM +, Christoph Hellwig wrote:
 On Wed, Jan 19, 2005 at 02:40:16PM -0800, Greg KH wrote:
  I had a patch to do that around here somewhere, but I think it was
  rejected as people can get the same info by using 'modinfo' instead.
  You know, the old, use a userspace tool instead of wasting kernel
  memory argument :)
 
 How's that supposed to work for builtin drivers?

Look at /sys/modules these days.  It shows all builtin modules now :)

Oh wait.  I get your point.  Hm, I don't know.  Want me to dig up the
patch?  It also added such unneeded things as module author and license
just to be complete.

thanks,

greg k-h
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drop some attibutes from the FC transport class

2005-01-19 Thread Matt Domsch
On Wed, Jan 19, 2005 at 03:42:19PM -0800, Greg KH wrote:
 Here it was against 2.6.9.  Odds are it doesn't apply anymore due to
 some recent changes in this area.  If anyone wants to take it and fix it
 up, please do so.
 
 Note, this patch needs the evil strdup() function to work properly.
 That's one of the main reasons I decided to not submit it to the main
 kernel tree...

How would you feel if instead, we just didn't drop the .modinfo
section?  That would eliminate the need to copy the strings, and then
the field##_get_function would just use the string from the .modinfo
section directly?

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com  www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html