On Sun, 2007-02-25 at 05:51 +, Christoph Hellwig wrote:
> > Well... I do not want any flame on this topic. It is about taste,
> > trade-offs, compromises. It is difficult to provide _objective_ and
> > killing arguments here. But I will think on this, point taken, thanks.
>
> Codingstyle is
On Sun, 2007-02-25 at 05:51 +, Christoph Hellwig wrote:
Well... I do not want any flame on this topic. It is about taste,
trade-offs, compromises. It is difficult to provide _objective_ and
killing arguments here. But I will think on this, point taken, thanks.
Codingstyle is and
On Mon, Feb 19, 2007 at 07:44:16PM +0200, Artem Bityutskiy wrote:
> On Mon, 2007-02-19 at 10:50 +, Christoph Hellwig wrote:
> > I think this is the wrong approach. For one thing the unit terms is
> > rather foregin in Linux
>
> I would rather disagree. Subjective. Unit is a generic word,
On Mon, Feb 19, 2007 at 07:07:46PM +0200, Artem Bityutskiy wrote:
> > And when you create that many interfaces, it adds inertia to changing
> > the interfaces later on, because it's sometimes not clear how many
> > users of the interface there really are. My general rule of thumb is
> > that if
On Tue, Feb 20, 2007 at 09:52:46AM -0500, John Stoffel wrote:
>
> Artem> This patch-set contains UBI, which stands for Unsorted Block
> Artem> Images. This is closely related to the memory technology
> Artem> devices Linux subsystem (MTD), so this new piece of software is
> Artem> from
On Tue, Feb 20, 2007 at 09:52:46AM -0500, John Stoffel wrote:
Artem This patch-set contains UBI, which stands for Unsorted Block
Artem Images. This is closely related to the memory technology
Artem devices Linux subsystem (MTD), so this new piece of software is
Artem from drivers/mtd/ubi.
On Mon, Feb 19, 2007 at 07:07:46PM +0200, Artem Bityutskiy wrote:
And when you create that many interfaces, it adds inertia to changing
the interfaces later on, because it's sometimes not clear how many
users of the interface there really are. My general rule of thumb is
that if an
On Mon, Feb 19, 2007 at 07:44:16PM +0200, Artem Bityutskiy wrote:
On Mon, 2007-02-19 at 10:50 +, Christoph Hellwig wrote:
I think this is the wrong approach. For one thing the unit terms is
rather foregin in Linux
I would rather disagree. Subjective. Unit is a generic word, just like
On Tue, 2007-02-20 at 09:52 -0500, John Stoffel wrote:
> Artem> This patch-set contains UBI, which stands for Unsorted Block
> Artem> Images. This is closely related to the memory technology
> Artem> devices Linux subsystem (MTD), so this new piece of software is
> Artem> from drivers/mtd/ubi.
>
John,
On Tue, 2007-02-20 at 09:52 -0500, John Stoffel wrote:
> Can you define UBI in each and every file you create? This is a
> completely unique acronym and I'm sure a bunch of people will be going
> "wtf" when they read this, I know I was.
Do you mean adding something like "This is file is a
Artem> This patch-set contains UBI, which stands for Unsorted Block
Artem> Images. This is closely related to the memory technology
Artem> devices Linux subsystem (MTD), so this new piece of software is
Artem> from drivers/mtd/ubi.
Can you define UBI in each and every file you create? This is a
On Mon, 2007-02-19 at 18:34 -0500, Theodore Tso wrote:
> Not that my opinion is the only
> one you need to pay attention to, but if everyone is telling you that
> need to simplify the number of interfaces, you may want to listen
> since your code is going to need adequate review if you want to get
On Mon, 2007-02-19 at 18:34 -0500, Theodore Tso wrote:
Not that my opinion is the only
one you need to pay attention to, but if everyone is telling you that
need to simplify the number of interfaces, you may want to listen
since your code is going to need adequate review if you want to get it
Artem This patch-set contains UBI, which stands for Unsorted Block
Artem Images. This is closely related to the memory technology
Artem devices Linux subsystem (MTD), so this new piece of software is
Artem from drivers/mtd/ubi.
Can you define UBI in each and every file you create? This is a
John,
On Tue, 2007-02-20 at 09:52 -0500, John Stoffel wrote:
Can you define UBI in each and every file you create? This is a
completely unique acronym and I'm sure a bunch of people will be going
wtf when they read this, I know I was.
Do you mean adding something like This is file is a part
On Tue, 2007-02-20 at 09:52 -0500, John Stoffel wrote:
Artem This patch-set contains UBI, which stands for Unsorted Block
Artem Images. This is closely related to the memory technology
Artem devices Linux subsystem (MTD), so this new piece of software is
Artem from drivers/mtd/ubi.
Can you
On Mon, Feb 19, 2007 at 07:07:46PM +0200, Artem Bityutskiy wrote:
> I just used different concept: one looks at declaration and the overall
> picture becomes clear because _there is_ documentation. One does not
> look at the implementation to grasp picture on surface.
>
> But your point is fair.
On Mon, 2007-02-19 at 10:50 +, Christoph Hellwig wrote:
> I think this is the wrong approach. For one thing the unit terms is
> rather foregin in Linux
I would rather disagree. Subjective. Unit is a generic word, just like
subsystem. Unit-tests for example is a widespread word it refer to
On Mon, 2007-02-19 at 09:33 -0500, Theodore Tso wrote:
> It made it much, much, MUCH harder to review. Especially given that
> the documentation was separated from the implementation. As I looked
> at the implementation, there was no way to look and what it was
> supposed to do without flipping
On Mon, Feb 19, 2007 at 02:48:23PM +0200, Artem Bityutskiy wrote:
> I actually did not mean these patches should be included to a git. We
> have UBI git to pull from for these purposes. I basically manually split
> the UBI sources to make UBI easier to review. I should have added an
> "RFC" tag,
Theodore,
On Sat, 2007-02-17 at 17:49 -0500, Theodore Tso wrote:
> This patch introduces the Makefile before any of the source
> files, which means it will break "git bisect" operations. Could you
> please refactor your patches so that the tree will build after any
> point in your patch
On Sat, Feb 17, 2007 at 06:54:24PM +0200, Artem Bityutskiy wrote:
> The structure of the UBI code is very simple. Whole UBI consists of units.
> Each unit has one .c file which implements it and one .h file which defines
> the interface of this unit. So I've split the UBI code so that there is
> a
On Sat, Feb 17, 2007 at 06:54:24PM +0200, Artem Bityutskiy wrote:
The structure of the UBI code is very simple. Whole UBI consists of units.
Each unit has one .c file which implements it and one .h file which defines
the interface of this unit. So I've split the UBI code so that there is
a
Theodore,
On Sat, 2007-02-17 at 17:49 -0500, Theodore Tso wrote:
This patch introduces the Makefile before any of the source
files, which means it will break git bisect operations. Could you
please refactor your patches so that the tree will build after any
point in your patch
On Mon, Feb 19, 2007 at 02:48:23PM +0200, Artem Bityutskiy wrote:
I actually did not mean these patches should be included to a git. We
have UBI git to pull from for these purposes. I basically manually split
the UBI sources to make UBI easier to review. I should have added an
RFC tag,
On Mon, 2007-02-19 at 09:33 -0500, Theodore Tso wrote:
It made it much, much, MUCH harder to review. Especially given that
the documentation was separated from the implementation. As I looked
at the implementation, there was no way to look and what it was
supposed to do without flipping back
On Mon, 2007-02-19 at 10:50 +, Christoph Hellwig wrote:
I think this is the wrong approach. For one thing the unit terms is
rather foregin in Linux
I would rather disagree. Subjective. Unit is a generic word, just like
subsystem. Unit-tests for example is a widespread word it refer to
On Mon, Feb 19, 2007 at 07:07:46PM +0200, Artem Bityutskiy wrote:
I just used different concept: one looks at declaration and the overall
picture becomes clear because _there is_ documentation. One does not
look at the implementation to grasp picture on surface.
But your point is fair. I
On Sat, Feb 17, 2007 at 06:54:24PM +0200, Artem Bityutskiy wrote:
> The structure of the UBI code is very simple. Whole UBI consists of units.
> Each unit has one .c file which implements it and one .h file which defines
> the interface of this unit. So I've split the UBI code so that there is
> a
Hello,
This patch-set contains UBI, which stands for Unsorted Block Images. This
is closely related to the memory technology devices Linux subsystem (MTD),
so this new piece of software is from drivers/mtd/ubi.
In short, UBI is kind of LVM layer but for flash (MTD) devices. It makes
it possible
Hello,
This patch-set contains UBI, which stands for Unsorted Block Images. This
is closely related to the memory technology devices Linux subsystem (MTD),
so this new piece of software is from drivers/mtd/ubi.
In short, UBI is kind of LVM layer but for flash (MTD) devices. It makes
it possible
On Sat, Feb 17, 2007 at 06:54:24PM +0200, Artem Bityutskiy wrote:
The structure of the UBI code is very simple. Whole UBI consists of units.
Each unit has one .c file which implements it and one .h file which defines
the interface of this unit. So I've split the UBI code so that there is
a
32 matches
Mail list logo
