On 11/09/2011 12:18, Artem Bityutskiy wrote:
On Fri, 2011-09-09 at 16:41 +0200, David Wagner wrote:
1. Stick with the own cdev approach - the driver becomes very simple
in this case - we review it.
This is the way it's implemented in v4, right ?
Yes, but I though I sent you some feed bac
On Fri, 2011-09-09 at 16:41 +0200, David Wagner wrote:
> > 1. Stick with the own cdev approach - the driver becomes very simple
> >in this case - we review it.
>
> This is the way it's implemented in v4, right ?
Yes, but I though I sent you some feed back with minor things as well as
with ma
On Fri, 2011-09-09 at 16:25 +0200, Arnd Bergmann wrote:
> On Friday 09 September 2011, Artem Bityutskiy wrote:
> > On Thu, 2011-09-08 at 17:26 +0200, Arnd Bergmann wrote:
> > > On Tuesday 06 September 2011, Artem Bityutskiy wrote:
> > > > Not sure about the bus approach - David, could you take a lo
On Friday 09 September 2011, David Wagner wrote:
> On 09/09/2011 01:53 PM, Artem Bityutskiy wrote:
> > On Thu, 2011-09-08 at 17:26 +0200, Arnd Bergmann wrote:
> >> On Tuesday 06 September 2011, Artem Bityutskiy wrote:
> >>> Not sure about the bus approach - David, could you take a look at it
> >>>
On 09/09/2011 01:53 PM, Artem Bityutskiy wrote:
> On Thu, 2011-09-08 at 17:26 +0200, Arnd Bergmann wrote:
>> On Tuesday 06 September 2011, Artem Bityutskiy wrote:
>>> Not sure about the bus approach - David, could you take a look at it
>>> please? If we can handle errors there - then we could indee
On Friday 09 September 2011, Artem Bityutskiy wrote:
> On Thu, 2011-09-08 at 17:26 +0200, Arnd Bergmann wrote:
> > On Tuesday 06 September 2011, Artem Bityutskiy wrote:
> > > Not sure about the bus approach - David, could you take a look at it
> > > please? If we can handle errors there - then we c
On Fri, 2011-09-09 at 14:53 +0300, Artem Bityutskiy wrote:
> David, I am really busy and now, I suggest you to think about this. I'd
> so far stick to the own ubiblk cdev approach, and would
> analyse/prototype the approach of using UBI cdev for this. I provided
> some concerns above. Also, think a
On Thu, 2011-09-08 at 17:26 +0200, Arnd Bergmann wrote:
> On Tuesday 06 September 2011, Artem Bityutskiy wrote:
> > Not sure about the bus approach - David, could you take a look at it
> > please? If we can handle errors there - then we could indeed re-use the
> > UBI control device. We could even
On Tuesday 06 September 2011, Artem Bityutskiy wrote:
> Not sure about the bus approach - David, could you take a look at it
> please? If we can handle errors there - then we could indeed re-use the
> UBI control device. We could even re-use the ioctl data structures for
> UBI volumes creation/remo
On Tue, 2011-09-06 at 07:10 +0300, Artem Bityutskiy wrote:
> On Tue, 2011-09-06 at 06:44 +0300, Artem Bityutskiy wrote:
> > > It's not a dummy bus, in this approach it would be a the bus that gets
> > > used by all ubiblk devices, which is a very common concept by itself.
> > > It's more like the c
On Tue, 2011-09-06 at 06:44 +0300, Artem Bityutskiy wrote:
> > It's not a dummy bus, in this approach it would be a the bus that gets
> > used by all ubiblk devices, which is a very common concept by itself.
> > It's more like the classic understanding of a 'device class' that Greg
> > wants to see
Hi, sorry for long delay, did not have time to read my mail.
On Thu, 2011-08-25 at 17:12 +0200, Arnd Bergmann wrote:
> > I think this wasteful. Why should I have block devices which I do not
> > need? If I have 4 UBI volumes, and need only one ubiblk, why should I
> > waste my resources for 3 more
On 08/25/2011 05:12 PM, Arnd Bergmann wrote:
> The cost of a block device node in the kernel is rather low. Nowadays,
> sysfs does not even permanently use inodes for entries, it has a much
> more compact internal representation IIRC.
>
> The main advantage of this approach is not having to set up
On Thursday 25 August 2011, Artem Bityutskiy wrote:
> On Wed, 2011-08-24 at 18:23 +0200, Arnd Bergmann wrote:
> > That should be fine, yes. I would probably put them into the same
> > header file though if they are in the same number space even
> > when you use them on distinct devices.
> >
> > I
Hi Arnd,
On Wed, 2011-08-24 at 18:23 +0200, Arnd Bergmann wrote:
> That should be fine, yes. I would probably put them into the same
> header file though if they are in the same number space even
> when you use them on distinct devices.
>
> It does feel a little clumsy to have yet another charac
On Monday 22 August 2011, Artem Bityutskiy wrote:
>
> On Wed, 2011-08-17 at 15:17 +0200, david.wag...@free-electrons.com
> wrote:
> > Questions:
> > ==
> > I wasn't sure what magic ioctl number to use, so I settled to use the same
> > one
> > as a part of UBI: 'O', which was so far only u
On Wed, 2011-08-17 at 15:17 +0200, david.wag...@free-electrons.com
wrote:
> Questions:
> ==
> I wasn't sure what magic ioctl number to use, so I settled to use the same one
> as a part of UBI: 'O', which was so far only used by UBI but on a higher range
> and leaving some room for UBI to ad
Hi,
thanks for the patch, it is quite good I think, but I still have few
comments. I did not review very carefully because of limited amount of
free time.
There are few checkpatch.pl complaints, could you please take a look?
Note, often I give a comment for one place, but there are many other
si
From: David Wagner
ubiblk is a read-only block layer on top of UBI. It presents UBI volumes as
read-only block devices (named ubiblk_X_Y, where X is the UBI device number
and Y the Volume ID).
It is used by putting a block filesystem image on a UBI volume, creating the
corresponding ubiblk devi
19 matches
Mail list logo
