From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: grub-probe detects ext4 wronly as ext2
Date: Wed, 2 Jul 2008 16:22:45 +0200 [thread overview]
Message-ID: <20080702142245.GA21064@thorin> (raw)
In-Reply-To: <1214954927.9353.91.camel@localhost>
On Wed, Jul 02, 2008 at 01:28:47AM +0200, Javier Martín wrote:
> > A --ignore-incompatible flag doesn't sound like a nice thing to do; it means
> > we're passing our own problem to the user instead of solving it.
> We don't have any "problem" to pass to users: ext4 is not supported
We don't have an urge to support ext4, but that doesn't mean we shouldn't
consider it a problem.
I think adding an interface for the user to choose in which way to deal with
our limitations is a nasty thing. I strongly object to that.
> and
> thus we do the Right Thing (tm) in patching our ext2 driver so that it
> won't try to read a filesystem it cannot.
That makes sense, with some caveats (see below).
> However, given Pavel's and
> others' objections, I suggested the addition of an user override to it.
> Thus, the user will have to knowingly force the system to interpret the
> filesystem with its current code, and accept any failures he might get,
> instead of the current behaviour of having the FS mounted automatically
> without checking incompatibilities (and then getting the errors anyway).
I don't think this is necessary. First, let's take for granted that our code
is in every situation smart enough not to crash when a filesystem isn't
readable (this should always be the case, since we might occasionaly be asked
to read corrupt filesystems). Then, what do flags mean?
If a flag means "GRUB won't be able to access this filesystem at all", we could
explicitly refuse to probe it, but then again our code must be graceful enough
to cope with it without crashing anyway (see above), so maybe it's not worth to
(depends on the time/size trade-off).
If a flag means "access to the filesystem isn't deterministic, and grub-probe
might be able to do things that real GRUB won't", then we're in a situation in
which we'd like grub-probe to be conservative _but_ real GRUB to be
best-effort. I think this means an internal switch to tell fs probes whether
to be conservative or not. We could even use #ifdef GRUB_UTIL so the flag
checking stuff doesn't make real GRUB fatter.
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)
next prev parent reply other threads:[~2008-07-02 14:23 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-29 18:11 grub-probe detects ext4 wronly as ext2 Felix Zielcke
2008-06-29 18:46 ` Javier Martín
2008-06-29 19:17 ` Bean
2008-06-29 19:53 ` Javier Martín
2008-06-29 21:19 ` Robert Millan
2008-06-30 3:02 ` Javier Martín
2008-06-30 7:10 ` Felix Zielcke
2008-06-30 11:14 ` Isaac Dupree
2008-06-30 12:12 ` Javier Martín
2008-06-30 12:27 ` Bean
2008-06-30 12:43 ` Javier Martín
2008-07-01 16:08 ` Robert Millan
2008-07-01 16:25 ` Pavel Roskin
2008-07-01 18:42 ` Javier Martín
2008-07-01 19:01 ` Pavel Roskin
2008-07-01 20:48 ` Robert Millan
2008-07-01 23:05 ` Javier Martín
2008-07-01 23:28 ` Javier Martín
2008-07-02 14:22 ` Robert Millan [this message]
2008-07-02 16:03 ` Pavel Roskin
2008-07-02 19:32 ` Javier Martín
2008-07-03 14:02 ` Robert Millan
2008-07-03 14:21 ` Isaac Dupree
2008-07-03 17:07 ` Javier Martín
2008-07-04 0:08 ` Robert Millan
2008-07-04 1:20 ` Javier Martín
2008-08-05 17:23 ` Felix Zielcke
2008-08-06 10:36 ` Felix Zielcke
2008-08-11 0:35 ` Javier Martín
2008-08-11 7:56 ` Felix Zielcke
2008-07-04 1:32 ` Javier Martín
2008-07-04 6:49 ` Bean
2008-07-04 8:33 ` Felix Zielcke
2008-07-04 10:34 ` Javier Martín
2008-07-04 11:29 ` Bean
2008-07-04 12:00 ` Javier Martín
2008-07-04 14:09 ` Robert Millan
2008-07-04 14:33 ` Javier Martín
2008-07-04 14:11 ` Bean
2008-07-04 14:34 ` Javier Martín
2008-07-04 14:04 ` Robert Millan
2008-07-04 14:23 ` Robert Millan
2008-07-04 14:21 ` Robert Millan
2008-07-04 14:45 ` Javier Martín
2008-07-04 18:57 ` Robert Millan
2008-07-04 20:41 ` Javier Martín
2008-07-05 12:07 ` Robert Millan
2008-07-05 18:36 ` Javier Martín
2008-07-16 15:09 ` Javier Martín
2008-07-16 15:27 ` Felix Zielcke
2008-07-16 16:38 ` Javier Martín
2008-07-16 17:13 ` Felix Zielcke
2008-07-16 17:21 ` Felix Zielcke
2008-07-16 17:44 ` Felix Zielcke
2008-07-16 19:07 ` Javier Martín
2008-07-16 19:33 ` Felix Zielcke
2008-07-19 14:27 ` Robert Millan
2008-08-11 14:14 ` Javier Martín
2008-08-27 13:58 ` Felix Zielcke
2008-08-30 11:17 ` Robert Millan
2008-08-30 21:28 ` Javier Martín
2008-09-24 17:05 ` Javier Martín
2009-02-04 7:41 ` Felix Zielcke
2009-02-04 13:08 ` Javier Martín
2009-02-07 19:30 ` Felix Zielcke
2009-02-07 23:54 ` Javier Martín
2009-02-08 0:28 ` Robert Millan
2008-07-01 16:03 ` Robert Millan
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=20080702142245.GA21064@thorin \
--to=rmh@aybabtu.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.