linux-kernel - Re: [Scst-devel] [PATCH 8/19]: SCST SYSFS interface implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CE2846C.6070501@vlnb.net>
Date:	Tue, 16 Nov 2010 16:17:32 +0300
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	Richard Williams <richard@...chsoft.com>
CC:	Bart Van Assche <bvanassche@....org>,
	Boaz Harrosh <bharrosh@...asas.com>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Mike Christie <michaelc@...wisc.edu>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	Greg KH <greg@...ah.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	scst-devel <scst-devel@...ts.sourceforge.net>,
	Hannes Reinecke <hare@...e.de>, Andy Yan <ayan@...vell.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vu Pham <vuhuong@...lanox.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Joel Becker <joel.becker@...cle.com>
Subject: Re: [Scst-devel] [PATCH 8/19]: SCST SYSFS interface implementation

(Since this discussion goes to a quite fundamental scope, I let myself
to add Joel Becker and Linus Torvalds on CC)

Richard Williams, on 11/16/2010 02:59 PM wrote:
> I'm just an outsider - but maybe my perspective has value - it seems
> there are two sides to this debate:
> 
> 1) sysfs is great for scst due to certain stability concerns and code
> concerns
> 2) sysfs is bad for scst due to the intended role of sysfs
> and its namespace

Your questions are very good, so let's summarize what we need to serve
the needs of a SCSI target subsystem (not necessary SCST) and see what
can fit them.

So, the needs:

1. Be capable to represent to user space internal configuration to let
user space be able to see and analyze it, including various statistics.

2. Let user space manage the internal configuration.

3. Desired: possibility to send to user space events about important
internal actions, like I/O failures, which may need user space
intervention to recover, like switching from active to passive role in a
cluster.

So, what can we do with ConfigFS:

(1): Only partially, because by design ConfigFS isn't supposed to
represent internal configuration, it can only manage it. Extending
ConfigFS to be capable to do that would be, in my understanding, a
strong violation of its purpose and, hence, design and if went this way
eventually ConfigFS would become just a duplication of the SYSFS
functionality.

(2): ConfigFS can do that. This is exactly for what it was designed and
implemented. But in this particular application it would have some
limitations derived from (1): to manage harware-related entries a user
should magically know from somewhen names of those entries to create
them by "mkdir" command.

For instance, consider a user has a Fibre Channel HBA and want to use it
in the target mode. Before he can configure it, he should somehow know
its ports names and for each of them run:

# mkdir /sys/kernel/config/.../50:50:00:00:00:00:00:11
# mkdir /sys/kernel/config/.../50:50:00:00:00:00:00:12
...

where 50:50:00:00:00:00:00:1x are the ports' names. Only after that
those ports appear on the ConfigFS and can be managed.

(3): No events at all.

Now consider SYSFS:

(1): Easily. This is exactly for what it was designed and implemented.

(2): Possible without any limitations and side effects.

(3): Also possible.

So, why not use SYSFS if it suits all the needs _without_ any additional
effort and patches?

Other alternatives? A set of custom IOCTLs? One more configuration FS? I
believe, those would be quite disgusting for all.

> Maybe I misunderstand - But if both sides have merit then wouldn't a
> compromise be appropriate?
> 
> Maybe the sensical compromise is to use sysfs code to create a new
> namespace that would fit this purpose?  It seems that I am also
> hearing that the alternatives to sysfs aren't always adequate - so
> why not use sysfs, but have a place where it's appropriate to use it?

This is exactly what we are proposing: to use SYSFS in additional
namespace /sys/kernel/scst_tgt.

As far as I can see, only Greg is against it. Greg keeps his reasons
private, so I can only guess that Greg is against extending usage of
SYSFS (note, _usage_, not implementation! Everything needed long ago
implemented.) beyond the scope it was originally designed around 10
years ago. But SYSFS is already widely used this way in the kernel, as
Joe illustrated, hence there is demand for it. People need it. So, why
not to just acknowledge this fact and go ahead the simplest and most
useful for both users and developers way?

Thanks,
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/