On Mon, Jun 21, 2010 at 06:21:09PM +0200, Markus Armbruster wrote:
> You describe the special case where format and protocol make some sense:
> you have a block driver that can transport bits in arbitrary formats,
> and a block driver that interprets bits without caring for transport.
>
> In the g
On Tue, Jun 22, 2010 at 05:40:02PM +0100, Jamie Lokier wrote:
> Kevin Wolf wrote:
> > > The "protocol" parlance breaks down when we move away from the simple
> > > stuff. For instance, qcow2 needs two children: the block driver
> > > providing the delta bits (in qcow2 format), and the block driver
Markus Armbruster wrote:
> A possible reason why we currently expose format and protocol at the
> user interface is to avoid stacking there.
Pragmatic solution?: A few generic flags in each stacking module
("format/protocol/transport"), which govern which other modules are
allowed to stack on top
Kevin Wolf wrote:
> > The "protocol" parlance breaks down when we move away from the simple
> > stuff. For instance, qcow2 needs two children: the block driver
> > providing the delta bits (in qcow2 format), and the block driver
> > providing the base bits (whose configuration happens to be stored
Christoph Hellwig wrote:
> On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
> > I can appreciate the desire to keep protocols and formats as an internal
> > distinction but as a user visible concept, I think your two examples
> > highlight why exposing protocols as formats make se
Kevin Wolf writes:
> Am 21.06.2010 18:21, schrieb Markus Armbruster:
>> Christoph Hellwig writes:
>>
[...]
>>> The user basically can specify two things:
>>>
>>> - a transport protocol. Normally this is just the filesystem
>>>interface, but it can also be nbd, http or for really sick peop
Am 21.06.2010 18:21, schrieb Markus Armbruster:
> Christoph Hellwig writes:
>
>> On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
>>> I can appreciate the desire to keep protocols and formats as an internal
>>> distinction but as a user visible concept, I think your two examples
Christoph Hellwig writes:
> On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
[...]
>> [2] -blockdev format=vvfat,file=/path/to/directory,id=blk1
>>
>>
>> It's not clear to me why [2] should be transport=vvfat. vvfat really
>> isn't a transport.
>
> Well, it's a wart if you wan
Christoph Hellwig writes:
> On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
>> I can appreciate the desire to keep protocols and formats as an internal
>> distinction but as a user visible concept, I think your two examples
>> highlight why exposing protocols as formats make se
On 06/21/2010 11:01 AM, Christoph Hellwig wrote:
On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
There's just a couple cases we should consider:
[1] -blockdev format=raw,file=/dev/cdrom,id=blk1
For [1], we just defaulting transport to file is would not give us th
On Mon, Jun 21, 2010 at 10:37:37AM -0500, Anthony Liguori wrote:
> There's just a couple cases we should consider:
>
> [1] -blockdev format=raw,file=/dev/cdrom,id=blk1
> For [1], we just defaulting transport to file is would not give us the
> same semantics we have today. Is that desirable?
By
On 06/21/2010 10:00 AM, Christoph Hellwig wrote:
Keeping these separate makes a lot of sense to me, even with my user
hat on. And as lon as we don't require the transport protocol but fall
back to file it's even more understandable for the users, as he simply
doesn't have to care about it for th
> The user basically can specify two things:
>
> - a transport protocol. Normally this is just the filesystem
>interface, but it can also be nbd, http or for really sick people
>vvfat. This is a setting which can't be guessed, btw - it needs
>to be explicitly set in some way, with f
On Mon, Jun 21, 2010 at 09:51:23AM -0500, Anthony Liguori wrote:
> I can appreciate the desire to keep protocols and formats as an internal
> distinction but as a user visible concept, I think your two examples
> highlight why exposing protocols as formats make sense. A user doesn't
> necessari
14 matches
Mail list logo
