[PATCH] UUID support for UFS

[PATCH] UUID support for UFS

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 106 bytes --]

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

[-- Attachment #2: ufs.diff --]
[-- Type: text/plain, Size: 2373 bytes --]

diff --git a/ChangeLog b/ChangeLog
index 02d5af1..f7275bd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2009-07-21  Vladimir Serbinenko  <phcoder@gmail.com>
 
+	UUID support for UFS
+	
+	* fs/ufs.c (grub_ufs_sblock): Add uuidhi and uuidlow.
+	(grub_ufs_uuid): New function.
+	(grub_ufs_fs): add .uuid
+
+2009-07-21  Vladimir Serbinenko  <phcoder@gmail.com>
+
 	* fs/ufs.c (grub_ufs_sblock): Fix offset of mtime2 which was off by
 	128 bytes
 
diff --git a/fs/ufs.c b/fs/ufs.c
index c9531b5..a41145e 100644
--- a/fs/ufs.c
+++ b/fs/ufs.c
@@ -87,7 +87,10 @@ struct grub_ufs_sblock
 
   /* The size of filesystem blocks to disk blocks.  */
   grub_uint32_t log2_blksz;
-  grub_uint8_t unused6[80];
+  grub_uint8_t unused6[40];
+  grub_uint32_t uuidhi;
+  grub_uint32_t uuidlow;
+  grub_uint8_t unused7[32];
 
   /* Inodes stored per cylinder group.  */
   grub_uint32_t ino_per_group;
@@ -95,14 +98,14 @@ struct grub_ufs_sblock
   /* The frags per cylinder group.  */
   grub_uint32_t frags_per_group;
 
-  grub_uint8_t unused7[488];
+  grub_uint8_t unused8[488];
 
   /* Volume name for UFS2.  */
   grub_uint8_t volume_name[GRUB_UFS_VOLNAME_LEN];
-  grub_uint8_t unused8[360];
+  grub_uint8_t unused9[360];
 
   grub_uint64_t mtime2;
-  grub_uint8_t unused9[292];
+  grub_uint8_t unused10[292];
 
   /* Magic value to check if this is really a UFS filesystem.  */
   grub_uint32_t magic;
@@ -736,6 +739,33 @@ grub_ufs_label (grub_device_t device, char **label)
   return grub_errno;
 }
 
+static grub_err_t
+grub_ufs_uuid (grub_device_t device, char **uuid)
+{
+  struct grub_ufs_data *data;
+  grub_disk_t disk = device->disk;
+
+  grub_dl_ref (my_mod);
+
+  data = grub_ufs_mount (disk);
+  if (data)
+    {
+      *uuid = grub_malloc (16 + sizeof ('\0'));
+      grub_sprintf (*uuid, "%08lx%08lx",
+		    (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
+		    (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
+    }
+  else
+    *uuid = NULL;
+
+  grub_dl_unref (my_mod);
+
+  grub_free (data);
+
+  return grub_errno;
+}
+
+
 /* Get mtime.  */
 static grub_err_t
 grub_ufs_mtime (grub_device_t device, grub_int32_t *tm)
@@ -769,6 +799,7 @@ static struct grub_fs grub_ufs_fs =
     .read = grub_ufs_read,
     .close = grub_ufs_close,
     .label = grub_ufs_label,
+    .uuid = grub_ufs_uuid,
     .mtime = grub_ufs_mtime,
     .next = 0
   };

Re: [PATCH] UUID support for UFS

[Pavel Roskin]

On Tue, 2009-07-21 at 15:03 +0200, Vladimir 'phcoder' Serbinenko wrote:
> +      grub_sprintf (*uuid, "%08lx%08lx",
> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));

unsigned long is 64-bit on x86_64.  unsigned int would do just fine
here.

Also, I don't see where this notation is used.  The FreeBSD dumpfs
prints two numbers in hex with a space between them.  On Linux, udev
doesn't create entries for UFS partitions under /dev/disk/by-uuid.
Linux kernel doesn't print UUID at all.

I would add a dash between the numbers to make it more readable unless
there is a precedent where the dash is not used.

Apart from that, the code looks good and the result matches the output
of dumpfs.

-- 
Regards,
Pavel Roskin

Re: [PATCH] UUID support for UFS

[Vladimir 'phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]

On Tue, Jul 21, 2009 at 7:14 PM, Pavel Roskin<proski@gnu.org> wrote:
> On Tue, 2009-07-21 at 15:03 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> +      grub_sprintf (*uuid, "%08lx%08lx",
>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
>
> unsigned long is 64-bit on x86_64.  unsigned int would do just fine
> here.
Ok
> I would add a dash between the numbers to make it more readable unless
> there is a precedent where the dash is not used.
If you look into /dev/ufsid/ then you'll see that it has no dash. This
is also a syntax used in
set FreeBSD.vfs.root.mountfrom=ufs:ufsid/<id>
So making it with dash would need additional conversion to pass it to FreeBSD
>
>
> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

[-- Attachment #2: ufs.diff --]
[-- Type: text/plain, Size: 2361 bytes --]

diff --git a/ChangeLog b/ChangeLog
index 02d5af1..f7275bd 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,13 @@
 2009-07-21  Vladimir Serbinenko  <phcoder@gmail.com>
 
+	UUID support for UFS
+	
+	* fs/ufs.c (grub_ufs_sblock): Add uuidhi and uuidlow.
+	(grub_ufs_uuid): New function.
+	(grub_ufs_fs): add .uuid
+
+2009-07-21  Vladimir Serbinenko  <phcoder@gmail.com>
+
 	* fs/ufs.c (grub_ufs_sblock): Fix offset of mtime2 which was off by
 	128 bytes
 
diff --git a/fs/ufs.c b/fs/ufs.c
index c9531b5..336507c 100644
--- a/fs/ufs.c
+++ b/fs/ufs.c
@@ -87,7 +87,10 @@ struct grub_ufs_sblock
 
   /* The size of filesystem blocks to disk blocks.  */
   grub_uint32_t log2_blksz;
-  grub_uint8_t unused6[80];
+  grub_uint8_t unused6[40];
+  grub_uint32_t uuidhi;
+  grub_uint32_t uuidlow;
+  grub_uint8_t unused7[32];
 
   /* Inodes stored per cylinder group.  */
   grub_uint32_t ino_per_group;
@@ -95,14 +98,14 @@ struct grub_ufs_sblock
   /* The frags per cylinder group.  */
   grub_uint32_t frags_per_group;
 
-  grub_uint8_t unused7[488];
+  grub_uint8_t unused8[488];
 
   /* Volume name for UFS2.  */
   grub_uint8_t volume_name[GRUB_UFS_VOLNAME_LEN];
-  grub_uint8_t unused8[360];
+  grub_uint8_t unused9[360];
 
   grub_uint64_t mtime2;
-  grub_uint8_t unused9[292];
+  grub_uint8_t unused10[292];
 
   /* Magic value to check if this is really a UFS filesystem.  */
   grub_uint32_t magic;
@@ -736,6 +739,33 @@ grub_ufs_label (grub_device_t device, char **label)
   return grub_errno;
 }
 
+static grub_err_t
+grub_ufs_uuid (grub_device_t device, char **uuid)
+{
+  struct grub_ufs_data *data;
+  grub_disk_t disk = device->disk;
+
+  grub_dl_ref (my_mod);
+
+  data = grub_ufs_mount (disk);
+  if (data)
+    {
+      *uuid = grub_malloc (16 + sizeof ('\0'));
+      grub_sprintf (*uuid, "%08x%08x",
+		    (unsigned) grub_le_to_cpu32 (data->sblock.uuidhi),
+		    (unsigned) grub_le_to_cpu32 (data->sblock.uuidlow));
+    }
+  else
+    *uuid = NULL;
+
+  grub_dl_unref (my_mod);
+
+  grub_free (data);
+
+  return grub_errno;
+}
+
+
 /* Get mtime.  */
 static grub_err_t
 grub_ufs_mtime (grub_device_t device, grub_int32_t *tm)
@@ -769,6 +799,7 @@ static struct grub_fs grub_ufs_fs =
     .read = grub_ufs_read,
     .close = grub_ufs_close,
     .label = grub_ufs_label,
+    .uuid = grub_ufs_uuid,
     .mtime = grub_ufs_mtime,
     .next = 0
   };

Re: [PATCH] UUID support for UFS

[Javier Martín]

Vladimir 'phcoder' Serbinenko escribió:
> On Tue, Jul 21, 2009 at 7:14 PM, Pavel Roskin<proski@gnu.org> wrote:
>> On Tue, 2009-07-21 at 15:03 +0200, Vladimir 'phcoder' Serbinenko wrote:
>>> +      grub_sprintf (*uuid, "%08lx%08lx",
>>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
>>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
>> unsigned long is 64-bit on x86_64.  unsigned int would do just fine
>> here.
> Ok
We could use the <inttypes.h> macros for [u]intN_t types:
       grub_sprintf (*uuid, PRIx32 "-" PRIx32,
                        grub_le_to_cpu32 (data->sblock.uuidhi),
                        grub_le_to_cpu32 (data->sblock.uuidlow));
Of course, our *printf functions would have to recognize them, and we'd 
have to provide a suitable default for the header if the system compiler 
is not C99 compliant, but I think it's a good step forwards.

I would be willing to implement such a header/change to the *printf 
functions if there's any interest in them.

Re: [PATCH] UUID support for UFS

[Pavel Roskin]

On Tue, 2009-07-21 at 20:46 +0200, Javier Martín wrote:
> Vladimir 'phcoder' Serbinenko escribió:
> > On Tue, Jul 21, 2009 at 7:14 PM, Pavel Roskin<proski@gnu.org> wrote:
> >> On Tue, 2009-07-21 at 15:03 +0200, Vladimir 'phcoder' Serbinenko wrote:
> >>> +      grub_sprintf (*uuid, "%08lx%08lx",
> >>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
> >>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
> >> unsigned long is 64-bit on x86_64.  unsigned int would do just fine
> >> here.
> > Ok
> We could use the <inttypes.h> macros for [u]intN_t types:
>        grub_sprintf (*uuid, PRIx32 "-" PRIx32,
>                         grub_le_to_cpu32 (data->sblock.uuidhi),
>                         grub_le_to_cpu32 (data->sblock.uuidlow));
> Of course, our *printf functions would have to recognize them, and we'd 
> have to provide a suitable default for the header if the system compiler 
> is not C99 compliant, but I think it's a good step forwards.
> 
> I would be willing to implement such a header/change to the *printf 
> functions if there's any interest in them.

I think we shouldn't overengineer this.  We don't support platforms
where int is not 32-bit.  If we add support for such platform, we'll
have more issues than just printf.

-- 
Regards,
Pavel Roskin

Re: [PATCH] UUID support for UFS

[Vladimir 'phcoder' Serbinenko]

On Tue, Jul 21, 2009 at 11:31 PM, Pavel Roskin<proski@gnu.org> wrote:
> On Tue, 2009-07-21 at 20:46 +0200, Javier Martín wrote:
>> Vladimir 'phcoder' Serbinenko escribió:
>> > On Tue, Jul 21, 2009 at 7:14 PM, Pavel Roskin<proski@gnu.org> wrote:
>> >> On Tue, 2009-07-21 at 15:03 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> >>> +      grub_sprintf (*uuid, "%08lx%08lx",
>> >>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
>> >>> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
>> >> unsigned long is 64-bit on x86_64.  unsigned int would do just fine
>> >> here.
>> > Ok
>> We could use the <inttypes.h> macros for [u]intN_t types:
>>        grub_sprintf (*uuid, PRIx32 "-" PRIx32,
>>                         grub_le_to_cpu32 (data->sblock.uuidhi),
>>                         grub_le_to_cpu32 (data->sblock.uuidlow));
>> Of course, our *printf functions would have to recognize them, and we'd
>> have to provide a suitable default for the header if the system compiler
>> is not C99 compliant, but I think it's a good step forwards.
>>
>> I would be willing to implement such a header/change to the *printf
>> functions if there's any interest in them.
>
> I think we shouldn't overengineer this.  We don't support platforms
> where int is not 32-bit.  If we add support for such platform, we'll
> have more issues than just printf.
>
This change would allow to produce a code which is cleaner, easier to
read and understand. However I'm opposed to modifying printf function
for it. Instead we could just define somewhere:
GRUB_PRIx32 "%x"
#ifdef LONG_SIZEOF == 8
GRUB_PRIx64 "%lx"
#else
GRUB_PRIx64 "%llx"
#endif

> --
> Regards,
> Pavel Roskin
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [PATCH] UUID support for UFS

[Pavel Roskin]

On Tue, 2009-07-21 at 23:45 +0200, Vladimir 'phcoder' Serbinenko wrote:

> This change would allow to produce a code which is cleaner, easier to
> read and understand. However I'm opposed to modifying printf function
> for it.

I think Javier misspoke or didn't realize that *printf doesn't need to
be modified.

>  Instead we could just define somewhere:
> GRUB_PRIx32 "%x"

Better yet, "x", as in libc.  That would allow for "%08x" that we need
for UUID.

But I would prefer that we work on fixing bugs rather than non-bugs.

-- 
Regards,
Pavel Roskin

Re: [PATCH] UUID support for UFS

[Javier Martín]

Pavel Roskin escribió:
> On Tue, 2009-07-21 at 23:45 +0200, Vladimir 'phcoder' Serbinenko wrote:
> 
>> This change would allow to produce a code which is cleaner, easier to
>> read and understand. However I'm opposed to modifying printf function
>> for it.
> 
> I think Javier misspoke or didn't realize that *printf doesn't need to
> be modified.
Indeed, I didn't realise so. All that's required is a grub_inttypes 
header that either takes from the system stdint.h types or just defines 
the macros you were discussing.
> 
>>  Instead we could just define somewhere:
>> GRUB_PRIx32 "%x"
> 
> Better yet, "x", as in libc.  That would allow for "%08x" that we need
> for UUID.
Yeah, that is the format used in libc. I copied the example wrong, 
without the "%08"s.
> 
> But I would prefer that we work on fixing bugs rather than non-bugs.
> 
"Fixing" this would allow us to have cleaner code, and separate "casual 
variables" from fixed-length variables. If we print int with %d and 
int32_t with PRId32, the impact of the subtle bugs that appear when we 
port across architectures will be reduced.

Re: [PATCH] UUID support for UFS

[Pavel Roskin]

On Tue, 2009-07-21 at 22:14 +0200, Javier Martín wrote:

> > But I would prefer that we work on fixing bugs rather than non-bugs.
> > 
> "Fixing" this would allow us to have cleaner code, and separate "casual 
> variables" from fixed-length variables. If we print int with %d and 
> int32_t with PRId32, the impact of the subtle bugs that appear when we 
> port across architectures will be reduced.

If int and int32_t are different types, gcc will warn about it, at least
for implicit conversion with data loss.

It's more likely that bugs will be introduced by that change, not fixed.
Besides, the code will be harder to read.

I'm not going to participate in this discussion anymore.  I'm working on
a real bug in the rmmod command that exists right now.  It's more
important than fixing potential bugs on architectures we don't support.

-- 
Regards,
Pavel Roskin

Re: [PATCH] UUID support for UFS

[Javier Martín]

Pavel Roskin escribió:
> On Tue, 2009-07-21 at 22:14 +0200, Javier Martín wrote:
> 
>>> But I would prefer that we work on fixing bugs rather than non-bugs.
>>>
>> "Fixing" this would allow us to have cleaner code, and separate "casual 
>> variables" from fixed-length variables. If we print int with %d and 
>> int32_t with PRId32, the impact of the subtle bugs that appear when we 
>> port across architectures will be reduced.
> 
> If int and int32_t are different types, gcc will warn about it, at least
> for implicit conversion with data loss.
Oh, yes... with the current build system and without -Werror, warnings 
are _very_ visible. </sarcasm> Besides, do we really have -Wconversion 
enabled? I don't know, but gcc tends to be quite silent when it comes to 
type conversion, mainly due to the laxitude it's used in *nix C 
programs. The cast in that code was all but implicit, and explicit casts 
tend to shut the compiler up.

> 
> It's more likely that bugs will be introduced by that change, not fixed.
> Besides, the code will be harder to read.
You say it'd be harder to read because the macros are newly-introduced 
(C99) and thus not widely know. However, they are pretty clear and 
self-explanatory once you google them the first time... and at the very 
least they call attention to themselves: an unknowing programmer would 
wonder what they are. Using a "normal" print specifier and a type cast 
does not.

Re: [PATCH] UUID support for UFS

[Pavel Roskin]

On Tue, 2009-07-21 at 23:34 +0200, Javier Martín wrote:

> > If int and int32_t are different types, gcc will warn about it, at least
> > for implicit conversion with data loss.
> Oh, yes... with the current build system and without -Werror, warnings 
> are _very_ visible. </sarcasm>

I just use
make >/dev/null

>  Besides, do we really have -Wconversion 
> enabled?

No.  Have you actually tried it?  It finds some interesting stuff.  For
instance, the return value of grub_file_seek().

We can clean whatever -Wconversion finds.  That may find some real bugs
and it will prepare us to supporting new architectures.

>  I don't know, but gcc tends to be quite silent when it comes to 
> type conversion, mainly due to the laxitude it's used in *nix C 
> programs. The cast in that code was all but implicit, and explicit casts 
> tend to shut the compiler up.

However, we are not adding support for architectures with non-32-bit int
type right now.  Things may improve by the time we start that effort.
New format specifiers can appear to deal with 32-bit numbers.

> > It's more likely that bugs will be introduced by that change, not fixed.
> > Besides, the code will be harder to read.
> You say it'd be harder to read because the macros are newly-introduced 
> (C99) and thus not widely know. However, they are pretty clear and 
> self-explanatory once you google them the first time... and at the very 
> least they call attention to themselves: an unknowing programmer would 
> wonder what they are. Using a "normal" print specifier and a type cast 
> does not.

OK, if you can do it if you want.  It would be great if you fix some
real bugs in process.

-- 
Regards,
Pavel Roskin

Re: [PATCH] UUID support for UFS

[Robert Millan]

On Tue, Jul 21, 2009 at 11:34:42PM +0200, Javier Martín wrote:
>> If int and int32_t are different types, gcc will warn about it, at least
>> for implicit conversion with data loss.
> Oh, yes... with the current build system and without -Werror, warnings  
> are _very_ visible. </sarcasm>

Javier, I think I told you once already, but if you're interested in
productive discussion you should drop that tone.

As for -Werror, we're already discussing about enabling it in another
thread.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] UUID support for UFS

[Javier Martín]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

El mié, 22-07-2009 a las 19:47 +0200, Robert Millan escribió:
> On Tue, Jul 21, 2009 at 11:34:42PM +0200, Javier Martín wrote:
> >> If int and int32_t are different types, gcc will warn about it, at least
> >> for implicit conversion with data loss.
> > Oh, yes... with the current build system and without -Werror, warnings  
> > are _very_ visible. </sarcasm>
> 
> Javier, I think I told you once already, but if you're interested in
> productive discussion you should drop that tone.
> 
> As for -Werror, we're already discussing about enabling it in another
> thread.
> 
I'm sorry for the exabrupt. Yes, you told me once and at 20 I should be
mature enough to not let myself down this path... I'll open a new thread
with the changes I'm proposing to types.h.

-- 
-- Lazy, Oblivious, Recurrent Disaster -- Habbit

[-- Attachment #2: Esto es una parte de mensaje firmado digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH] UUID support for UFS

[Robert Millan]

On Tue, Jul 21, 2009 at 11:45:59PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> This change would allow to produce a code which is cleaner, easier to
> read and understand. However I'm opposed to modifying printf function
> for it. Instead we could just define somewhere:
> GRUB_PRIx32 "%x"
> #ifdef LONG_SIZEOF == 8
> GRUB_PRIx64 "%lx"
> #else
> GRUB_PRIx64 "%llx"
> #endif

This is unnecessary.  We defined the data as grub_uint32_t, so just dropping
the 'l' and the `unsigned long' casts should do.

As Pavel said, if we ever support a platform where sizeof(int) != 4, we have
more serious problems to worry about.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] UUID support for UFS

[Pavel Roskin]

On Tue, 2009-07-21 at 22:01 +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Tue, Jul 21, 2009 at 7:14 PM, Pavel Roskin<proski@gnu.org> wrote:
> > On Tue, 2009-07-21 at 15:03 +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> +      grub_sprintf (*uuid, "%08lx%08lx",
> >> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
> >> +                   (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
> >
> > unsigned long is 64-bit on x86_64.  unsigned int would do just fine
> > here.
> Ok
> > I would add a dash between the numbers to make it more readable unless
> > there is a precedent where the dash is not used.
> If you look into /dev/ufsid/ then you'll see that it has no dash. This
> is also a syntax used in
> set FreeBSD.vfs.root.mountfrom=ufs:ufsid/<id>
> So making it with dash would need additional conversion to pass it to FreeBSD

OK then.

-- 
Regards,
Pavel Roskin

Re: [PATCH] UUID support for UFS

[Robert Millan]

On Tue, Jul 21, 2009 at 03:03:34PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> +  grub_uint32_t uuidhi;
> +  grub_uint32_t uuidlow;
> [...]
> +      grub_sprintf (*uuid, "%08lx%08lx",
> +		    (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
> +		    (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));

Is this really being interpreted as mixed endian by other programs?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] UUID support for UFS

[Vladimir 'phcoder' Serbinenko]

On Wed, Jul 22, 2009 at 7:40 PM, Robert Millan<rmh@aybabtu.com> wrote:
> On Tue, Jul 21, 2009 at 03:03:34PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> +  grub_uint32_t uuidhi;
>> +  grub_uint32_t uuidlow;
>> [...]
>> +      grub_sprintf (*uuid, "%08lx%08lx",
>> +                 (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
>> +                 (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
>
> Is this really being interpreted as mixed endian by other programs?
>
Yes. It completely matches the ufsid used by FreeBSD. Actually uuidhi
seems to be creation timestamp and uuidlow just a random number but it
doesn't matter for GRUB.
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [PATCH] UUID support for UFS

[Pavel Roskin]

On Wed, 2009-07-22 at 19:40 +0200, Robert Millan wrote:
> On Tue, Jul 21, 2009 at 03:03:34PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > +  grub_uint32_t uuidhi;
> > +  grub_uint32_t uuidlow;
> > [...]
> > +      grub_sprintf (*uuid, "%08lx%08lx",
> > +		    (unsigned long) grub_le_to_cpu32 (data->sblock.uuidhi),
> > +		    (unsigned long) grub_le_to_cpu32 (data->sblock.uuidlow));
> 
> Is this really being interpreted as mixed endian by other programs?

I also wondered about it.  Yes, it's "mixed endian" in the dumpfs output
and in the kernel log.

-- 
Regards,
Pavel Roskin