[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CE2834F.9080509@vlnb.net>
Date: Tue, 16 Nov 2010 16:12:47 +0300
From: Vladislav Bolkhovitin <vst@...b.net>
To: "Nicholas A. Bellinger" <nab@...ux-iscsi.org>
CC: Bart Van Assche <bvanassche@....org>,
Boaz Harrosh <bharrosh@...asas.com>, Greg KH <greg@...ah.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
scst-devel <scst-devel@...ts.sourceforge.net>,
James Bottomley <James.Bottomley@...senpartnership.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 8/19]: SCST SYSFS interface implementation
Nicholas A. Bellinger, on 11/15/2010 11:19 PM wrote:
>> I think that Vlad has already explained several times why ConfigFS is
>> not suited for the needs of a storage target: a storage target must
>> not only be able to accept configuration information from userspace
>> but must also be able to create new directories and file nodes itself.
>> See e.g. this message from October 6:
>> http://kerneltrap.org/mailarchive/linux-kernel/2010/10/6/4628664.
>
> Sorry, but this post explains nothing but a single misguided and
> uninformed opinion, with no hard facts on the actual usage of a native
> configfs control plane within target mode infrastructure.
What is "misguided and uninformed opinion"? That you can't with ConfigFS
serve real life needs for target driver developers and can't create
targets for hardware target ports from withing the kernel and instead
enforce users to clumsy workarounds to somehow magically know their
names to manually perform "mkdir target_name"?
The same problem exists for all other objects where you need to create
ConfigFS entries (directories), like for per-session/per-initiator
statistics or default ACLs.
ConfigFS is just too simple to serve real life needs of a SCSI target
subsystem.
Vlad
--
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