On Sun, 2007-02-25 at 05:45 +, Christoph Hellwig wrote:
> It's definitively not safe for userspace - packed is not an ISO C thing
> and there's no guarantee userspace compilers understand it. Also you
> really don't want to use packed in new code, if you really need oddly
> aligned types it's
On Sun, 2007-02-25 at 05:50 +, Christoph Hellwig wrote:
> > I do not see what is the problem with this. Please, refine.
>
> global variables are very bad for code maintainability and understanadbility.
> So we usually try to avoid them if possible and make them static to a
> single file and pr
On Sun, Feb 25, 2007 at 05:50:11AM +, Christoph Hellwig wrote:
> global variables are very bad for code maintainability and understanadbility.
> So we usually try to avoid them if possible and make them static to a
> single file and provide proper accessors for allowed actions on them.
Another
On Tue 2007-02-20 15:33:18, David Woodhouse wrote:
> On Tue, 2007-02-20 at 10:22 -0500, Theodore Tso wrote:
> > But __be32 will catch the same errors these days because the be/le
> > types use __bitwise now, right? So use of the __be32/__be64 types should
> > be preferred since it also will work w
On Sun, 2007-02-25 at 05:43 +, Christoph Hellwig wrote:
> > The technique Artem uses is derived from what I do in JFFS2. It predates
> > the use of sparse to catch such errors, and works in gcc for _everyone_
> > without having to do anything special (like run sparse).
>
> And makes the code c
On Tue, Feb 20, 2007 at 03:05:53PM +0200, Artem Bityutskiy wrote:
> > Having this kind of global information directly exposed is a very
> > bad idea. In general you only want to access it through more
> > specific information and avoid allocating the global array at all.
>
> I do not see what is
On Tue, Feb 20, 2007 at 05:21:48PM +0200, Artem Bityutskiy wrote:
> > In that case it's not an *implementation* version number, but rather
> > an on-disk *format* version number.
>
> True, will refine the comment.
>
> > There's a difference. It's also
> > often not used much, since another way
On Tue, Feb 20, 2007 at 05:24:15PM +0200, Artem Bityutskiy wrote:
> On Tue, 2007-02-20 at 15:15 +, David Woodhouse wrote:
> > On Tue, 2007-02-20 at 09:55 -0500, Theodore Tso wrote:
> > > It appears that the reason why you are doing this is because you think
> > > you need the (packed) attribute
On Tue, Feb 20, 2007 at 03:15:55PM +, David Woodhouse wrote:
> > It would be much better to use __be32 and __be64, so you get better
> > type checking, and you will catch bugs caused by forgetting to use
> > be32_to_cpu, et. al.
>
> The technique Artem uses is derived from what I do in JFFS2.
On Tue, 2007-02-20 at 11:12 -0500, Theodore Tso wrote:
> I thought it was a gcc attribute as well, but it looks like it
> isn't.
Indeed, which is why I've never really been tempted to switch JFFS2 to
__[bl]e32 rather than the structures it currently uses. Sparse is all
very nice and all, but n
On Tue, Feb 20, 2007 at 03:33:18PM +, David Woodhouse wrote:
> On Tue, 2007-02-20 at 10:22 -0500, Theodore Tso wrote:
> > But __be32 will catch the same errors these days because the be/le
> > types use __bitwise now, right? So use of the __be32/__be64 types should
> > be preferred since it al
On Tue, 2007-02-20 at 10:22 -0500, Theodore Tso wrote:
> But __be32 will catch the same errors these days because the be/le
> types use __bitwise now, right? So use of the __be32/__be64 types should
> be preferred since it also will work with sparse, I would think.
Does __bitwise work in gcc? I t
On Tue, 2007-02-20 at 15:15 +, David Woodhouse wrote:
> On Tue, 2007-02-20 at 09:55 -0500, Theodore Tso wrote:
> > It appears that the reason why you are doing this is because you think
> > you need the (packed) attribute. Not needed; Linux assumes all over
> > the place 16, 32, and 64 types a
On Tue, 2007-02-20 at 09:55 -0500, Theodore Tso wrote:
> BTW, it might also be a good idea to run UBI through sparse to catch bugs.
Ran it before, will do before the next submission iteration.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
-
To unsubscribe from this list: send the line "uns
On Tue, 2007-02-20 at 09:55 -0500, Theodore Tso wrote:
> > What do you mean? It is internal version just for future help: if we
> > develop incompatible UBI2 the old UBI will reject the new images.
>
> In that case it's not an *implementation* version number, but rather
> an on-disk *format* versi
On Tue, Feb 20, 2007 at 03:15:55PM +, David Woodhouse wrote:
> > It would be much better to use __be32 and __be64, so you get better
> > type checking, and you will catch bugs caused by forgetting to use
> > be32_to_cpu, et. al.
>
> The technique Artem uses is derived from what I do in JFFS2.
On Tue, 2007-02-20 at 09:55 -0500, Theodore Tso wrote:
> It appears that the reason why you are doing this is because you think
> you need the (packed) attribute. Not needed; Linux assumes all over
> the place 16, 32, and 64 types are packed. If Linux is ever compiled
> on an architecture where t
On Tue, Feb 20, 2007 at 03:05:53PM +0200, Artem Bityutskiy wrote:
> On Mon, 2007-02-19 at 10:54 +, Christoph Hellwig wrote:
> > On Sat, Feb 17, 2007 at 06:54:49PM +0200, Artem Bityutskiy wrote:
> > > +#ifndef __UBI_UBI_H__
> > > +#define __UBI_UBI_H__
> > > +
> > > +#include
> > > +
> > > +/*
On Mon, 2007-02-19 at 10:54 +, Christoph Hellwig wrote:
> On Sat, Feb 17, 2007 at 06:54:49PM +0200, Artem Bityutskiy wrote:
> > +#ifndef __UBI_UBI_H__
> > +#define __UBI_UBI_H__
> > +
> > +#include
> > +
> > +/* Version of this UBI implementation */
> > +#define UBI_VERSION 1
> We shouldn't ha
On Mon, Feb 19, 2007 at 10:54:45AM +, Christoph Hellwig wrote:
> On Sat, Feb 17, 2007 at 06:54:49PM +0200, Artem Bityutskiy wrote:
> > +#ifndef __UBI_UBI_H__
> > +#define __UBI_UBI_H__
> > +
> > +#include
> > +
> > +/* Version of this UBI implementation */
> > +#define UBI_VERSION 1
>
> We sh
On Sat, 2007-02-17 at 22:05 +0100, Arnd Bergmann wrote:
> > +/* Maximum number of supported UBI devices */
> > +#define UBI_MAX_INSTANCES 32
>
> Does this need to be limited?
It is how this is implemented at the moment. Note, this limits number of
UBI devices, not ubi _volumes_.
> > +/* UBI erro
On Sat, Feb 17, 2007 at 06:54:49PM +0200, Artem Bityutskiy wrote:
> +#ifndef __UBI_UBI_H__
> +#define __UBI_UBI_H__
> +
> +#include
> +
> +/* Version of this UBI implementation */
> +#define UBI_VERSION 1
We shouldn't have versions for inkernel interfaces.
> +/* UBI messages printk level */
> +#
On Saturday 17 February 2007 17:54, Artem Bityutskiy wrote:
> +/* Maximum number of supported UBI devices */
> +#define UBI_MAX_INSTANCES 32
Does this need to be limited?
> +/* UBI messages printk level */
> +#define UBI_MSG_LEVEL KERN_INFO
> +#define UBI_WARN_LEVEL KERN_WARNING
> +#define UBI_
diff -auNrp tmp-from/drivers/mtd/ubi/ubi.h tmp-to/drivers/mtd/ubi/ubi.h
--- tmp-from/drivers/mtd/ubi/ubi.h 1970-01-01 02:00:00.0 +0200
+++ tmp-to/drivers/mtd/ubi/ubi.h2007-02-17 18:07:26.0 +0200
@@ -0,0 +1,100 @@
+/*
+ * Copyright (c) International Business Machines Cor
24 matches
Mail list logo
