linux-kernel - Re: [PATCH 49/50] mars: generic pre-patch for mars

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: <53B4F3D9.8050009@1und1.de>
Date:	Thu, 03 Jul 2014 08:10:33 +0200
From:	Thomas Schöbel-Theuer <tst@...d1.de>
To:	Christoph Hellwig <hch@...radead.org>
CC:	Greg KH <gregkh@...uxfoundation.org>,
	Thomas Schoebel-Theuer <tst@...oebel-theuer.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 49/50] mars: generic pre-patch for mars

>> Please take into account that MARS Light is not just a "device driver",
>> but a long-distance distributed system dealing with huge masses of state
>> information.
> Which doesn't matter.  No kernel driver has a business messing with the
> filesystem namespace.  Especially no maintaining magic symlink farms.
>

I see the following alternative solutions for this:

a) MARS Light cannot go upstream because it is viewed as a driver
violating the rules. In this case, I could retry submission some years
laters when (subsets of) MARS Full strictly obey some hierarchy rules
which I have to know completely in advance in order to no longer make
any mistakes. However, I am not sure whether the limits in the solution
space are really appropriate for the problem space; I would have to make
new prototype implementations and compare them to other solutions. Only
after that, I would be able to decide whether to go upstream at all, or
to continue an out-of-tree project.

or

b) you permit me exceptions from the rules, justified by the fact that a
_distributed_ "driver" for long-distance replication of terabytes of
data (constructed for long-distance replication of _whole_ _datacenters_
) needs dynamically growing storage space for bulk data. In order to not
re-invent the wheel, you permit me storing both data and metadata in a
reserved filesystem instance. Storing metadata _together_ with the
_corresponding_ (!) bulk data is justified by the fact that separate
storage spaces would need some additional means for ensuring
_consistency_ between them in case of node failures etc.

or

c) MARS Light is viewed as a distributed system, similar to a cluster
filesystem, which just happens to export a block device to userspace (at
current stage of development; notice that the generic brick framework is
not limited to the block device layer).

or

d) both MARS Light and the future Full is viewed as a new generic
framework. In current stage, only some parts dealing with block devices
are implemented. In later stages of MARS Full, the future hierarchy
rules will be automatically checked / established by some future
strategy bricks, according to IOP design principles as proposed in my
papers / in my monography (a detailed discussion is probably out of
scope of this discussion).

Possibly there are further alternatives.

At least in cases c) and d), the sourcecode should IMHO not go to
drivers/block/ but somewhere else (please give me some suggestions; this
is why ./rework-mars-for-upstream.pl has is easily configurable).

Cheers,

Thomas

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