From: "Javier Martín" <lordhabbit@gmail.com>
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 17:06:10 +0200 [thread overview]
Message-ID: <1220195170.2622.33.camel@localhost> (raw)
In-Reply-To: <1220192824.4354.11.camel@fz.local>
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
El dom, 31-08-2008 a las 16:27 +0200, Felix Zielcke escribió:
> > > The specs say that it's allowed to contain only zeros but I think this
> > > shouldn't be a big problem.
> >
> > I think this could indeed be a problem if it leads to collisions. If "all
> > zeroes" is detected, one could rise an error in uuid() function to prevent the
> > caller from taking the value into consideration.
>
> I have now used grub_error (GRUB_ERR_BAD_NUMBER)
>
> 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.
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:
/* ... */
grub_error (GRUB_ERR_BAD_NUMBER, "No creation date in
filesystem to generate UUID.");
if (uuid)
*uuid = NULL;
}
else
{
if (uuid)
{
*uuid = /* ... */
-Habbit
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
next prev parent reply other threads:[~2008-08-31 15: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 [this message]
2008-08-31 16:03 ` Felix Zielcke
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=1220195170.2622.33.camel@localhost \
--to=lordhabbit@gmail.com \
--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.