All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felix Zielcke <fzielcke@z-51.de>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] iso9660 UUID support by using the creation date/time
Date: Sun, 31 Aug 2008 18:03:46 +0200	[thread overview]
Message-ID: <1220198626.4354.25.camel@fz.local> (raw)
In-Reply-To: <1220195170.2622.33.camel@localhost>

Am Sonntag, den 31.08.2008, 17:06 +0200 schrieb Javier Martín:

Hello Javier,

> El dom, 31-08-2008 a las 16:27 +0200, Felix Zielcke escribió:
> > 
> > But maybe it would be better to make a new type for this, though I don't
> > have yet an idea how to call it.
> > Suggestions please :)
> What about:
>  * BAD_FS looks the most contextual here, but if the ISO9660 standard
> allows filesystems to "lack" the creation date, then they are certainly
> not "bad", though for the purposes of the uuid function they are -
> slightly confusing.
>  * BAD_ARGUMENT as in "the FS you requested to id is not a valid
> argument to this function", but this err code is usually applied for the
> failure of argument precondition checks (non-empty device names, etc.)
>  * INVALID_COMMAND as in "this command cannot be applied to that FS"
>  * Or even NOT_IMPLEMENTED_YET as in "we still haven't figured how to id
> this FS", but this seems to imply that we will eventually do.

Yep not really easy to find a correct one, but luckly not that important
on grub2's sourcecode the values aren't that often exactly checked as
far as I could see.
This is probable just about `coding style'
Well let's see and wait.

> By the way, reviewing BAD_ARGUMENT has reminded me that maybe the
> function should check whether "uuid" is valid. If not, you don't need to
> abort the operation, just the  malloc and consequent sprintf. If
> implemented like this in all other FSs, this would be a fast way to
> check whether or not a particular FS can have an UUID extracted without
> actually having to get the id itself:

Actually it is currently in a fast way implemented.
iso9660 filesystem currently doestn't have any UUID function at all,
because it doestn't have one strictly speaking.
For normal filesystems if the specs say they have an UUID field they
normally always should have one.
But the problem with iso9660 is that the specs say that the creation
date which I use can be just zeros.
I tend now too like Robert that no UUID for iso9660 + printing an error
might be better then an UUID containing just zeros.


util/grub-probe.c

      if (! fs->uuid)
        grub_util_error ("%s does not support UUIDs", fs->name);

      fs->uuid (dev, &uuid);


For example fs/cpio.c still has no uuid function at all :)

-- 
Felix Zielcke




  reply	other threads:[~2008-08-31 16:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-30 20:15 [PATCH] iso9660 UUID support by using the creation date/time Felix Zielcke
2008-08-30 21:08 ` Felix Zielcke
2008-08-31 13:47 ` Robert Millan
2008-08-31 14:27   ` Felix Zielcke
2008-08-31 15:06     ` Javier Martín
2008-08-31 16:03       ` Felix Zielcke [this message]
2008-08-31 16:56     ` Robert Millan
2008-08-31 17:23       ` Felix Zielcke
2008-08-31 18:40         ` Robert Millan
2008-08-31 18:55           ` Felix Zielcke
2008-09-05 17:02             ` Felix Zielcke
2008-09-06 11:11               ` Robert Millan
2008-09-06 11:17                 ` Felix Zielcke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1220198626.4354.25.camel@fz.local \
    --to=fzielcke@z-51.de \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.