Fixed up a couple spots that were out of line with the PAPR in regards
to its defined VSCSI protocol. Did away with some magic numbers directly
in the code. Fixed a minor endian issue.
Tyrel Datwyler (6):
ibmvscsi: Correct values for several viosrp_crq_format enums
ibmvscsi: Add and use enums for valid CRQ header values
ibmvscsi: Replace magic values in set_adpater_info() with defines
ibmvscsi: Use of_root to access OF device tree root node
ibmvscsi: Remove unsupported host config MAD and sysfs interface
ibmvscsi: Add endian conversions to sysfs attribute show functions
drivers/scsi/ibmvscsi/ibmvscsi.c | 117 +++++++--------------------------------
drivers/scsi/ibmvscsi/viosrp.h | 20 ++++---
2 files changed, 30 insertions(+), 107 deletions(-)
--
2.5.0
The values returned by the show functions for the host os_type,
mad_version, and partition_number attributes get their values
directly from the madapter_info struct whose associated fields are
__be32 typed. Added endian conversion to ensure these values are
sane on LE platforms.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
From: Johannes Thumshirn <hidden> Date: 2016-02-04 08:45:56
On Wed, Feb 03, 2016 at 05:28:34PM -0600, Tyrel Datwyler wrote:
quoted hunk
The values returned by the show functions for the host os_type,
mad_version, and partition_number attributes get their values
directly from the madapter_info struct whose associated fields are
__be32 typed. Added endian conversion to ensure these values are
sane on LE platforms.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn <redacted>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn <redacted>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
A VIOSRP_HOST_CONFIG_TYPE management datagram (MAD) has existed in
the code for some time. From what information I've gathered from
Brian King this was likely implemented on the host side in a SLES 9
based VIOS, which is no longer supported anywhere. Further, it is
not defined in PAPR or supported by any AIX based VIOS.
Treating as bit rot and removing the sysfs interface and associated
host config code accordingly.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 78 ----------------------------------------
drivers/scsi/ibmvscsi/viosrp.h | 7 ----
2 files changed, 85 deletions(-)
@@ -1853,62 +1853,6 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,}/**-*ibmvscsi_get_host_config:Sendthecommandtotheservertogethost-*configurationdata.Thedataisopaquetous.-*/-staticintibmvscsi_do_host_config(structibmvscsi_host_data*hostdata,-unsignedchar*buffer,intlength)-{-structviosrp_host_config*host_config;-structsrp_event_struct*evt_struct;-unsignedlongflags;-dma_addr_taddr;-intrc;--evt_struct=get_event_struct(&hostdata->pool);-if(!evt_struct){-dev_err(hostdata->dev,"couldn't allocate event for HOST_CONFIG!\n");-return-1;-}--init_event_struct(evt_struct,-sync_completion,-VIOSRP_MAD_FORMAT,-info_timeout);--host_config=&evt_struct->iu.mad.host_config;--/* The transport length field is only 16-bit */-length=min(0xffff,length);--/* Set up a lun reset SRP command */-memset(host_config,0x00,sizeof(*host_config));-host_config->common.type=cpu_to_be32(VIOSRP_HOST_CONFIG_TYPE);-host_config->common.length=cpu_to_be16(length);-addr=dma_map_single(hostdata->dev,buffer,length,DMA_BIDIRECTIONAL);--if(dma_mapping_error(hostdata->dev,addr)){-if(!firmware_has_feature(FW_FEATURE_CMO))-dev_err(hostdata->dev,-"dma_mapping error getting host config\n");-free_event_struct(&hostdata->pool,evt_struct);-return-1;-}--host_config->buffer=cpu_to_be64(addr);--init_completion(&evt_struct->comp);-spin_lock_irqsave(hostdata->host->host_lock,flags);-rc=ibmvscsi_send_srp_event(evt_struct,hostdata,info_timeout*2);-spin_unlock_irqrestore(hostdata->host->host_lock,flags);-if(rc==0)-wait_for_completion(&evt_struct->comp);-dma_unmap_single(hostdata->dev,addr,length,DMA_BIDIRECTIONAL);--returnrc;-}--/***ibmvscsi_slave_configure:Setthe"allow_restart"flagforeachdisk.*@sdev:structscsi_devicedevicetoconfigure*
From: Johannes Thumshirn <hidden> Date: 2016-02-04 08:03:22
On Wed, Feb 03, 2016 at 05:28:33PM -0600, Tyrel Datwyler wrote:
A VIOSRP_HOST_CONFIG_TYPE management datagram (MAD) has existed in
the code for some time. From what information I've gathered from
Brian King this was likely implemented on the host side in a SLES 9
based VIOS, which is no longer supported anywhere. Further, it is
not defined in PAPR or supported by any AIX based VIOS.
Treating as bit rot and removing the sysfs interface and associated
host config code accordingly.
Doesn't removing a sysfs interface potentially break userspace code?
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
On Wed, Feb 03, 2016 at 05:28:33PM -0600, Tyrel Datwyler wrote:
quoted
A VIOSRP_HOST_CONFIG_TYPE management datagram (MAD) has existed in
the code for some time. From what information I've gathered from
Brian King this was likely implemented on the host side in a SLES 9
based VIOS, which is no longer supported anywhere. Further, it is
not defined in PAPR or supported by any AIX based VIOS.
Treating as bit rot and removing the sysfs interface and associated
host config code accordingly.
Doesn't removing a sysfs interface potentially break userspace code?
In the general case yes, but I feel in this case no. First, Reading from
this config attribute of a vscsi host adapter always returns nothing.
Second, any userspace code using this attribute better be checking for
the existence of config. Just a quick look for
/sys/class/scsi_host/host*/config under other host adapters on my system
I find that attribute doesn't exist for any of them.
If there is truly enough concern that somebody may actually be accessing
this useless attribute from userspace then we can still strip out the
unsupported code, but leave the attribute and return nothing directly
from the show function.
-Tyrel
From: Johannes Thumshirn <hidden> Date: 2016-02-05 08:34:22
On Thu, Feb 04, 2016 at 09:48:23AM -0800, Tyrel Datwyler wrote:
On 02/04/2016 12:03 AM, Johannes Thumshirn wrote:
quoted
On Wed, Feb 03, 2016 at 05:28:33PM -0600, Tyrel Datwyler wrote:
quoted
A VIOSRP_HOST_CONFIG_TYPE management datagram (MAD) has existed in
the code for some time. From what information I've gathered from
Brian King this was likely implemented on the host side in a SLES 9
based VIOS, which is no longer supported anywhere. Further, it is
not defined in PAPR or supported by any AIX based VIOS.
Treating as bit rot and removing the sysfs interface and associated
host config code accordingly.
Doesn't removing a sysfs interface potentially break userspace code?
In the general case yes, but I feel in this case no. First, Reading from
this config attribute of a vscsi host adapter always returns nothing.
Second, any userspace code using this attribute better be checking for
the existence of config. Just a quick look for
/sys/class/scsi_host/host*/config under other host adapters on my system
I find that attribute doesn't exist for any of them.
If there is truly enough concern that somebody may actually be accessing
this useless attribute from userspace then we can still strip out the
unsupported code, but leave the attribute and return nothing directly
from the show function.
Which is what I kinda prefer. Slowly deprecate and phase out, but don't break
userspace. You never know who is writing some obscure piece of code relaying on
some sysfs attribute.
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
The root node of the OF device tree is exported as of_root. No need
to look up the root by path name. Instead just get a reference
directly via of_root.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
@@ -248,25 +248,23 @@ static void ibmvscsi_task(void *data)staticvoidgather_partition_info(void){-structdevice_node*rootdn;-constchar*ppartition_name;const__be32*p_number_ptr;/* Retrieve information about this partition */-rootdn=of_find_node_by_path("/");-if(!rootdn){+if(!of_root)return;-}-ppartition_name=of_get_property(rootdn,"ibm,partition-name",NULL);+of_node_get(of_root);++ppartition_name=of_get_property(of_root,"ibm,partition-name",NULL);if(ppartition_name)strncpy(partition_name,ppartition_name,sizeof(partition_name));-p_number_ptr=of_get_property(rootdn,"ibm,partition-no",NULL);+p_number_ptr=of_get_property(of_root,"ibm,partition-no",NULL);if(p_number_ptr)partition_number=of_read_number(p_number_ptr,1);-of_node_put(rootdn);+of_node_put(of_root);}staticvoidset_adapter_info(structibmvscsi_host_data*hostdata)
From: Johannes Thumshirn <hidden> Date: 2016-02-04 08:45:40
On Wed, Feb 03, 2016 at 05:28:32PM -0600, Tyrel Datwyler wrote:
quoted hunk
The root node of the OF device tree is exported as of_root. No need
to look up the root by path name. Instead just get a reference
directly via of_root.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
@@ -248,25 +248,23 @@ static void ibmvscsi_task(void *data)staticvoidgather_partition_info(void){-structdevice_node*rootdn;-constchar*ppartition_name;const__be32*p_number_ptr;/* Retrieve information about this partition */-rootdn=of_find_node_by_path("/");-if(!rootdn){+if(!of_root)return;-}-ppartition_name=of_get_property(rootdn,"ibm,partition-name",NULL);+of_node_get(of_root);++ppartition_name=of_get_property(of_root,"ibm,partition-name",NULL);if(ppartition_name)strncpy(partition_name,ppartition_name,sizeof(partition_name));-p_number_ptr=of_get_property(rootdn,"ibm,partition-no",NULL);+p_number_ptr=of_get_property(of_root,"ibm,partition-no",NULL);if(p_number_ptr)partition_number=of_read_number(p_number_ptr,1);-of_node_put(rootdn);+of_node_put(of_root);}staticvoidset_adapter_info(structibmvscsi_host_data*hostdata)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn <redacted>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
The PAPR defines four valid header values for the first byte of a
CRQ message. Namely, an unused/empty message (0x00), a valid
command/response entry (0x80), a valid initialization entry (0xC0),
and a transport event (0xFF). Define these values as enums and use
them in the code in place of their magic number equivalents.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 14 +++++++-------
drivers/scsi/ibmvscsi/viosrp.h | 7 +++++++
2 files changed, 14 insertions(+), 7 deletions(-)
@@ -231,7 +231,7 @@ static void ibmvscsi_task(void *data)/* Pull all the valid messages off the CRQ */while((crq=crq_queue_next_crq(&hostdata->queue))!=NULL){ibmvscsi_handle_crq(crq,hostdata);-crq->valid=0x00;+crq->valid=VIOSRP_CRQ_FREE;}vio_enable_interrupts(vdev);
@@ -1791,7 +1791,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,dev_err(hostdata->dev,"unknown crq message type: %d\n",crq->format);}return;-case0xFF:/* Hypervisor telling us the connection is closed */+caseVIOSRP_CRQ_TRANSPORT:/* Hypervisor telling us the connection is closed */scsi_block_requests(hostdata->host);atomic_set(&hostdata->request_limit,0);if(crq->format==0x06){
@@ -1807,7 +1807,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,ibmvscsi_reset_host(hostdata);}return;-case0x80:/* real payload */+caseVIOSRP_CRQ_VALID:/* real payload */break;default:dev_err(hostdata->dev,"got an invalid message type 0x%02x\n",
From: Johannes Thumshirn <hidden> Date: 2016-02-04 08:39:23
On Wed, Feb 03, 2016 at 05:28:30PM -0600, Tyrel Datwyler wrote:
quoted hunk
The PAPR defines four valid header values for the first byte of a
CRQ message. Namely, an unused/empty message (0x00), a valid
command/response entry (0x80), a valid initialization entry (0xC0),
and a transport event (0xFF). Define these values as enums and use
them in the code in place of their magic number equivalents.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 14 +++++++-------
drivers/scsi/ibmvscsi/viosrp.h | 7 +++++++
2 files changed, 14 insertions(+), 7 deletions(-)
@@ -231,7 +231,7 @@ static void ibmvscsi_task(void *data)/* Pull all the valid messages off the CRQ */while((crq=crq_queue_next_crq(&hostdata->queue))!=NULL){ibmvscsi_handle_crq(crq,hostdata);-crq->valid=0x00;+crq->valid=VIOSRP_CRQ_FREE;}vio_enable_interrupts(vdev);
@@ -1791,7 +1791,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,dev_err(hostdata->dev,"unknown crq message type: %d\n",crq->format);}return;-case0xFF:/* Hypervisor telling us the connection is closed */+caseVIOSRP_CRQ_TRANSPORT:/* Hypervisor telling us the connection is closed */scsi_block_requests(hostdata->host);atomic_set(&hostdata->request_limit,0);if(crq->format==0x06){
@@ -1807,7 +1807,7 @@ static void ibmvscsi_handle_crq(struct viosrp_crq *crq,ibmvscsi_reset_host(hostdata);}return;-case0x80:/* real payload */+caseVIOSRP_CRQ_VALID:/* real payload */break;default:dev_err(hostdata->dev,"got an invalid message type 0x%02x\n",
@@ -51,6 +51,13 @@ union srp_iu {u8reserved[SRP_MAX_IU_LEN];};+enumviosrp_crq_headers{+VIOSRP_CRQ_FREE=0x00,+VIOSRP_CRQ_VALID=0x80,+VIOSRP_CRQ_INIT=0xC0,+VIOSRP_CRQ_TRANSPORT=0xFF+};+enumviosrp_crq_formats{VIOSRP_SRP_FORMAT=0x01,VIOSRP_MAD_FORMAT=0x02,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn <redacted>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
The PAPR defines four valid header values for the first byte of a
CRQ message. Namely, an unused/empty message (0x00), a valid
command/response entry (0x80), a valid initialization entry (0xC0),
and a transport event (0xFF). Define these values as enums and use
them in the code in place of their magic number equivalents.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 14 +++++++-------
drivers/scsi/ibmvscsi/viosrp.h | 7 +++++++
2 files changed, 14 insertions(+), 7 deletions(-)
After the switch to enums, bitwise operators are a bit misleading.
Especially in this case since multiple values would satisfy this
condition: VIOSRP_CRQ_VALID, VIOSRP_CRQ_INIT and
VIOSRP_CRQ_TRANSPORT.
If 'valid' will only have one of these four enums defined, would
this be better written as:
if (crq->valid != VIOSRP_CRQ_FREE)
quoted hunk
if (++queue->cur == queue->size)
queue->cur = 0;
@@ -231,7 +231,7 @@ static void ibmvscsi_task(void *data) /* Pull all the valid messages off the CRQ */ while ((crq = crq_queue_next_crq(&hostdata->queue)) != NULL) { ibmvscsi_handle_crq(crq, hostdata);- crq->valid = 0x00;+ crq->valid = VIOSRP_CRQ_FREE; } vio_enable_interrupts(vdev);
The PAPR defines four valid header values for the first byte of a
CRQ message. Namely, an unused/empty message (0x00), a valid
command/response entry (0x80), a valid initialization entry (0xC0),
and a transport event (0xFF). Define these values as enums and use
them in the code in place of their magic number equivalents.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 14 +++++++-------
drivers/scsi/ibmvscsi/viosrp.h | 7 +++++++
2 files changed, 14 insertions(+), 7 deletions(-)
After the switch to enums, bitwise operators are a bit misleading.
Especially in this case since multiple values would satisfy this
condition: VIOSRP_CRQ_VALID, VIOSRP_CRQ_INIT and
VIOSRP_CRQ_TRANSPORT.
Yeah, I can see how that is confusing. Since, all three possible valid
crq message types have the first bit set I think this was originally a
cute hack to grab anything that was likely valid. Then in
ibmvscsi_handle_crq() we explicitly match the full header value in a
switch statement logging anything that turned out actually invalid.
If 'valid' will only have one of these four enums defined, would
this be better written as:
if (crq->valid != VIOSRP_CRQ_FREE)
This definitely would make the logic easier to read and follow. Also,
this would make sure any crq with an invalid header that doesn't have
its first bit set will also be logged by the ibmvscsi_handle_crq()
switch statement default block and not silently ignored.
-Tyrel
quoted
if (++queue->cur == queue->size)
queue->cur = 0;
@@ -231,7 +231,7 @@ static void ibmvscsi_task(void *data) /* Pull all the valid messages off the CRQ */ while ((crq = crq_queue_next_crq(&hostdata->queue)) != NULL) { ibmvscsi_handle_crq(crq, hostdata);- crq->valid = 0x00;+ crq->valid = VIOSRP_CRQ_FREE; } vio_enable_interrupts(vdev);
Yeah, I can see how that is confusing. Since, all three possible valid
crq message types have the first bit set I think this was originally a
cute hack to grab anything that was likely valid. Then in
ibmvscsi_handle_crq() we explicitly match the full header value in a
switch statement logging anything that turned out actually invalid.
quoted
If 'valid' will only have one of these four enums defined, would
this be better written as:
if (crq->valid != VIOSRP_CRQ_FREE)
This definitely would make the logic easier to read and follow. Also,
this would make sure any crq with an invalid header that doesn't have
its first bit set will also be logged by the ibmvscsi_handle_crq()
switch statement default block and not silently ignored.
-Tyrel
Sounds good, Tyrel. Does this mean I should expect a v2 of this patch
series?
- Manoj N. Kumar
Yeah, I can see how that is confusing. Since, all three possible valid
crq message types have the first bit set I think this was originally a
cute hack to grab anything that was likely valid. Then in
ibmvscsi_handle_crq() we explicitly match the full header value in a
switch statement logging anything that turned out actually invalid.
quoted
If 'valid' will only have one of these four enums defined, would
this be better written as:
if (crq->valid != VIOSRP_CRQ_FREE)
This definitely would make the logic easier to read and follow. Also,
this would make sure any crq with an invalid header that doesn't have
its first bit set will also be logged by the ibmvscsi_handle_crq()
switch statement default block and not silently ignored.
-Tyrel
Sounds good, Tyrel. Does this mean I should expect a v2 of this patch
series?
- Manoj N. Kumar
Haven't had a chance to clean up and resubmit, but yes there will be a
v2 coming along soon.
-Tyrel
The enum values for VIOSRP_LINUX_FORMAT and VIOSRP_INLINE_FORMAT are
off by one. They are currently defined as 0x06 and 0x07 respetively.
These values are defined in PAPR correctly as 0x05 and 0x06. This
inconsistency has gone unnoticed as neither enum is currently used.
The possible future support of PING messages between the VIOS and
client adapter relies on VIOSRP_INLINE_FORMAT crq messages.
Corrected these enum values to match PAPR definitions.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/viosrp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Johannes Thumshirn <hidden> Date: 2016-02-04 08:38:37
On Wed, Feb 03, 2016 at 05:28:29PM -0600, Tyrel Datwyler wrote:
quoted hunk
The enum values for VIOSRP_LINUX_FORMAT and VIOSRP_INLINE_FORMAT are
off by one. They are currently defined as 0x06 and 0x07 respetively.
These values are defined in PAPR correctly as 0x05 and 0x06. This
inconsistency has gone unnoticed as neither enum is currently used.
The possible future support of PING messages between the VIOS and
client adapter relies on VIOSRP_INLINE_FORMAT crq messages.
Corrected these enum values to match PAPR definitions.
Signed-off-by: Tyrel Datwyler <redacted>
---
drivers/scsi/ibmvscsi/viosrp.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn <redacted>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850