To: linux-kernel@vger.kernel.org
MIME-Version: 1.0
Subject: Re: [PATCH 1/3] s390: dasd extended error reporting module.
Message-ID: <OFEACB8C3E.85A0843D-ONC125710D.00631F1E-C125710D.006451D4@de.ibm.com>
From: Stefan Weinhuber <WEIN@de.ibm.com>
Date: Mon, 6 Feb 2006 19:15:45 +0100
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1426
Lines: 36

Jan Blunck <jblunck@suse.de> wrote on 06.02.2006 12:30:46:

> Why don't you use the sysfs for this purpose? This new character device
> interface seems very odd to me. Why don't you introduce new attributes 
to the
> dasd device for that purpose and make online pollable for failovers?

We need to transfer binary data records, and in case of an error
situation probably quite a number of them. Maybe sysfs could be bent to
that purpose but to me this seems even more awkward then a character 
device.

> Or use dm-netlink to report the extended errors via multipath to the 
user
> space.

Our interface is supposed to work under memory constrained situations
e.g. when the connection to the storage device failed. With our character
device we can constrain memory allocations to uncritical situations:
- when error reporting is enabled
- when the device is opened
- when the internal buffer size is adjusted
The error reporting itself is done without any additional allocations.

Best Regards /  Mit freundlichen Gr??en

Stefan Weinhuber

-------------------------------------------------------------------
IBM Deutschland Entwicklung GmbH
Linux for zSeries Development & Services
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/