Re: The Linux FAT issue on SD Cards.. maintainer support please

2005-08-10 Thread Marc Singer
On Thu, Aug 11, 2005 at 10:57:14AM +0530, Mukund JB. wrote:
> Dear all,
> 
> I am Linux driver programmer. 
> 
> I have a FAT12 issue on my SD cards. I have got these addresses from the
> fs-lists as the maintainer support mail IDs for FAT-FS.
> 
> I am using the 2.6.10 kernel, X86 like systems.
> 
> I am NOT able to mount the Camera formatted FAT12 filesystem on my linux
> BOX. SD card is of size 16MB. At the same time I am able to mount the SD
> cards formatted in windows & linux.
> 
> I have identified fat_fill_super() in fs/fat/inode.c file as the
> function that reads the super block of as MS-DOS FS.
> 
> To debug, I have rebuilt my kernel 2.6.10 inserting some debug messages
> in the FS sub-system to know what data is coming into "struct
> fat_boot_sector *b" structure in fs/fat/inode.c file after sb_bread()
> call.
> 
> I believe that this data in the "struct fat_boot_sector *b" should be
> FAT12 information.
> 
> On the camera formatted SD that is NOT mounting I have found this
> structure to be all '0' till total_sectors variable (relevant till here
> on - FAT12).
> 
> Will you please verify if there & tell me if the problem is in the FAT
> sub-system.

Alternatively, you can dump the first block of the device/partition.
>From that, you can determine if there is a partition table.  In any
case, you can read the first block of the partition (or whole device)
and get the filesystem parameter block.

It should be easy from there to determine if the data can be
recognized as FAT.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] spi

2005-08-09 Thread Marc Singer
On Tue, Aug 09, 2005 at 10:54:34AM -0700, Andy Isaacson wrote:
> On Mon, Aug 08, 2005 at 10:47:21AM -0700, Marc Singer wrote:
> > On Mon, Aug 08, 2005 at 07:35:36PM +0200, Marcel Holtmann wrote:
> > > > > + if (NULL == dev || NULL == driver) {
> > > > 
> > > > Put the variable on the left side, gcc will complain if you incorrectly
> > > > put a "=" instead of a "==" here, which is all that you are defending
> > > > against with this style.
> > > 
> > > I think in this case the preferred way is
> > > 
> > >   if (!dev || !driver) {
> > > 
> > 
> > That's not a guaranteed equivalence in the C standard.  Null pointers
> > may not be zero.  I don't think we have any targets that work this
> > way, however there is nothing wrong with explicitly testing for NULL.
> 
> False.  The expression  "!x" is precisely equivalent to "x==0", no
> matter what the type of x is. [1]  And furthermore, NULL==0. [2]
> Ergo, "NULL == dev" and "!dev" are defined to be equivalent.
> 
> What you're confused about is that the *representation* of a null
> pointer constant does not necessarily have to be all-bits-zero.  That
> is, the following code fragment might print something on a
> standard-compliant C implementation:

No, I'm not confused about the representation of a NULL.  Keep in mind
that telling someone what they do or don't
understand/believe/think/feel is the fast track to being flamed.

> 
>   void *a = 0; unsigned char *p = (unsigned char *)&a;
>   int i;
>   for(i=0; i   if(p[i] != 0) printf("p[%d] = %02x!\n", i, p[i]);
> 
> That does not change the fact that the source-code fragment "NULL" is
> defined to be equivalent to the source-code fragment "0".  Simply the
> compiler must do whatever trickery necessary to ensure the correct
> values get generated in the object code for my above hypothetical
> architecture when I say "void *a = 0;".
> 
> This is very similar to how floating point is handled in the abstract
> machine definition of the standard.  Consider a weird FP implementation
> where 0.0 has a not-all-bits-zero representation, and change 'a' in my
> example above to type 'double'.  Just because 0.0 is stored as the bit
> pattern 0x8000 does not mean that I have to write something
> other than "double a = 0;"!
> 
> And furthermore, all of this was well-understood in the C89 standard;
> it's not new in the C99 standard, although there are some
> clarifications.
> 
> [1] ISO/IEC 9899:1999 6.5.3.3 Unary arithmetic operators
> 
>   (5) The result of the logical negation operator ! is 0 if the value of
>   its operand compares unequal to 0, 1 if the value of its operand
>   compares equal to 0. The result has type int.  The expression !E is
>   equivalent to (0==E).
> 
> [2] ISO/IEC 9899:1999 7.17
> 
>   The following types and macros are defined in the standard header
>   .  ...
>  NULL
>   which expands to an implementation-defined null pointer constant...
> 
>  and 6.3.2.3 Pointers
>   (3) An integer constant expression with the value 0, or such an
>   expression cast to type void *, is called a null pointer constant.

It was explained to me that the !pointer test wasn't guaranteed to be
equivalent because of the way that the test is handled.  The spec
fragments above don't address how the boolean test is coerced.  Does
it cast pointer to an integer and perform the test, or does it cast
the 0 to a pointer and perform the test.  The C++ spec I have is vague
on this point.  The only reference it makes to pointers is that the
operand for ! may be a pointer.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] spi

2005-08-08 Thread Marc Singer
On Mon, Aug 08, 2005 at 07:35:36PM +0200, Marcel Holtmann wrote:
> > > + if (NULL == dev || NULL == driver) {
> > 
> > Put the variable on the left side, gcc will complain if you incorrectly
> > put a "=" instead of a "==" here, which is all that you are defending
> > against with this style.
> 
> I think in this case the preferred way is
> 
>   if (!dev || !driver) {
> 

That's not a guaranteed equivalence in the C standard.  Null pointers
may not be zero.  I don't think we have any targets that work this
way, however there is nothing wrong with explicitly testing for NULL.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: kernel guide to space

2005-07-13 Thread Marc Singer
On Wed, Jul 13, 2005 at 01:22:04PM -0400, Lee Revell wrote:
> On Tue, 2005-07-12 at 23:58 -0700, Paul Jackson wrote:
> > Dick Johnson wrote:
> > > Or just disallow tabs altogether. At Analogic we ...
> > 
> > This is the Linux kernel, not Analogic.
> > 
> > We use tabs for indentation.  You can set the number
> > of physical spaces per tab however you want in your
> > editor, but it had better look good (and stay within
> > 80 columns)
> 
> I don't think there's a strict 80 column rule anymore.  It's 2005...

Think again.  There are a lot of people who use 80 column windows so
that we can see two code windows side-by-side.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/