[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49400C81.3010801@vlnb.net>
Date: Wed, 10 Dec 2008 21:37:53 +0300
From: Vladislav Bolkhovitin <vst@...b.net>
To: linux-scsi@...r.kernel.org
CC: James Bottomley <James.Bottomley@...senPartnership.com>,
Andrew Morton <akpm@...ux-foundation.org>,
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
Mike Christie <michaelc@...wisc.edu>,
Jeff Garzik <jeff@...zik.org>,
Boaz Harrosh <bharrosh@...asas.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, scst-devel@...ts.sourceforge.net,
Bart Van Assche <bart.vanassche@...il.com>,
"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
Subject: [PATCH][RFC 5/23]: SCST /proc interface
This patch contains SCST the /proc interface.
A description of this interface can be found in the patch with the
SCST core documentation.
Since a procfs-based configuration interface is unacceptable for new
kernel modules, in the next review iteration SCST's configuration
interface will be replaced by a sysfs-based configuration interface.
This patch is not intended to be included in the Linux kernel, but is
posted here, because as of today this configuration interface is
necessary when using SCST.
Unfortunately, configfs is not (yet) suited for configuring SCST. This
is, because configfs is user space driven, so kernel can't create
subdirectories on it, and all files on configfs are limited to 4K in
size. It makes impossible for kernel to show, e.g., a list of connected
initiators. Hence, with configfs it is necessary to have one more
interface to show such data, e.g. sysfs-based. It would lead to 2
interfaces in two different places for configuring SCSI targets:
configfs and sysfs based. Definitely, it is better to have only one,
sysfs-based interface, than 2 interfaces. From other side, sysfs in what
SCST needs provides basically the same possibilities as configfs. And
it's widely used in the kernel to configure various its parameters. See,
for instance, bonding devices or IO schedulers.
The proposed /sys interface would be very similar to the current /proc
layout intact, except cases, where output >PAGE_SIZE is needed. For such
cases each entry, i.e. line, in such files would be presented as a
subdirectory with name the first element in that line and each other
element in it would be presented as a separate file (attribute). For
instance, /proc/scsi_tgt/sessions, which lists connected sessions, would
be converted to:
/sys/scsi_tgt/
/sys/scsi_tgt/sessions/
/sys/scsi_tgt/sessions/session1_name/
/sys/scsi_tgt/sessions/session1_name/target_name
/sys/scsi_tgt/sessions/session1_name/initiator_name
/sys/scsi_tgt/sessions/session1_name/acl -> ../../acls/aclX
/sys/scsi_tgt/sessions/session1_name/commands
/sys/scsi_tgt/sessions/session2_name/
/sys/scsi_tgt/sessions/session2_name/target_name
/sys/scsi_tgt/sessions/session2_name/initiator_name
/sys/scsi_tgt/sessions/session2_name/acl -> ../../acls/aclY
/sys/scsi_tgt/sessions/session2_name/commands
.
.
.
Addition of new, e.g. vdisk devices, would be done via echo'ing commands
to, in this example, /sys/scsi_tgt/vdisk/mgmt file similarly as it's
currently done with /proc/scsi_tgt/vdisk/vdisk (same commands, actually).
Any comments and suggestions will be greatly appreciated.
Signed-off-by: Vladislav Bolkhovitin <vst@...b.net>
---
drivers/scst/scst_proc.c | 2196
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 2196 insertions(+)
The patch is too big to be submitted inline. You can find it in
http://scst.sourceforge.net/patches/scst_proc.diff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists