ext2 find patch

ext2 find patch

[Tomas Ebenlendr]

I don't understand the ext2 fs very well, but when I tried to install
grub2 on my computer, I had no access to files in subdirectories.

I installed bochs and tried to find what happened. And I found a strange
thing: newly created ext2 haven't this problem. So I use ext2resize to
get from real filesystem smaller image (1.44M floppy). It is ext2,
e2fsck tells it is clean, but dirent.filetype == 0 even for directories.
So I moved the directory check to another place, and changed it to test
inode.mode. Here is the patch (cvs diff -u):

----------------------------------------------------------------------------
Index: fs/ext2.c
===================================================================
RCS file: /cvsroot/grub/grub2/fs/ext2.c,v
retrieving revision 1.6
diff -u -r1.6 ext2.c
--- fs/ext2.c	4 Apr 2004 13:46:00 -0000	1.6
+++ fs/ext2.c	1 Jun 2004 12:12:19 -0000
@@ -422,6 +422,15 @@
       if (grub_errno)
    goto fail;
       
+      /* Check if it is directory */
+      /* NOTE: dirent.filetype==FILETYPE_DIRECTORY check sometimes fails,
+       * (I don't know why,) but this will not */
+      if (!(grub_le_to_cpu16 (inode->mode) & 040000))
+	{
+	   grub_error (GRUB_ERR_BAD_FILE_TYPE, "not a directory");
+	   goto fail;
+	}
+
       /* Search the file.  */
       while (fpos < grub_le_to_cpu32 (inode->size))
    {
@@ -526,12 +535,6 @@
	      currinode = grub_le_to_cpu32 (dirent.inode);
	      name = next;
 
-		      if (dirent.filetype != FILETYPE_DIRECTORY)
-			{
-			  grub_error (GRUB_ERR_BAD_FILE_TYPE,
-				      "not a directory");
-			  goto fail;
-			}
	      break;
	    }
	  else /* Found it!  */
----------------------------------------------------------------------------
-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.41690175319

Re: ext2 find patch

[Tomas Ebenlendr]

The same problem was with symlinks, so the new version of patch is here.

It does stat every inode (and ignore the info in direntries).
There is also small fix in absolute symlinks (chopping the initial '/')

--------------------------------------------------------------------------
Index: fs/ext2.c
===================================================================
RCS file: /cvsroot/grub/grub2/fs/ext2.c,v
retrieving revision 1.6
diff -u -r1.6 ext2.c
--- fs/ext2.c	4 Apr 2004 13:46:00 -0000	1.6
+++ fs/ext2.c	1 Jun 2004 20:11:28 -0000
@@ -401,6 +401,11 @@
   if (name[grub_strlen (name) - 1] =='/')
     name[grub_strlen (name) - 1] = '\0';
 
+  /* Open the file.  */
+  grub_ext2_read_inode (data, currinode, inode);
+  if (grub_errno)
+    goto fail;
+  
   while (*name)
     {
       unsigned int fpos = 0;
@@ -417,11 +422,6 @@
 
       namesize = grub_strlen (name);
 
-      /* Open the file.  */
-      grub_ext2_read_inode (data, currinode, inode);
-      if (grub_errno)
-	goto fail;
-      
       /* Search the file.  */
       while (fpos < grub_le_to_cpu32 (inode->size))
 	{
@@ -451,8 +451,13 @@
 	      if (dirent.namelen == namesize 
 		  && !grub_strncmp (name, filename, namesize))
 		{
+		  /* Stat the inode.  */
+		  grub_ext2_read_inode (data, 
+					grub_le_to_cpu32 (dirent.inode),
+					inode);
+
 		  /* If this is a symlink, follow it.  */
-		  if (dirent.filetype == FILETYPE_SYMLINK)
+		  if ((grub_le_to_cpu16 (data->inode.mode) &0170000) == 0120000)
 		    {
 		      /* XXX: Use malloc instead?  */
 		      char symlink[blocksize];
@@ -464,11 +469,6 @@
 			  goto fail;
 			}
 
-		      /* Read the symlink.  */
-		      grub_ext2_read_inode (data, 
-					    grub_le_to_cpu32 (dirent.inode),
-					    inode);
-
 		      /* If the filesize of the symlink is bigger than
 			 60 the symlink is stored in a separate block,
 			 otherwise it is stored in the inode.  */
@@ -490,7 +490,7 @@
 		      /* Check if the symlink is absolute or relative.  */
 		      if (symlink[0] == '/')
 			{
-			  grub_strncpy (fpath, symlink, EXT2_PATH_MAX);
+			  grub_strncpy (fpath, symlink + 1, EXT2_PATH_MAX);
 			  name = fpath;
 			  currinode = 2;
 			}
@@ -517,6 +517,11 @@
 			    }
 			}
 		  
+		      /* Open the file.  */
+		      grub_ext2_read_inode (data, currinode, inode);
+		      if (grub_errno)
+			goto fail;
+  
 		      fpos = 0;
 		      break;
 		    }
@@ -526,7 +531,7 @@
 		      currinode = grub_le_to_cpu32 (dirent.inode);
 		      name = next;
 
-		      if (dirent.filetype != FILETYPE_DIRECTORY)
+		      if ((grub_le_to_cpu16 (data->inode.mode) &0170000) != 040000)
 			{
 			  grub_error (GRUB_ERR_BAD_FILE_TYPE,
 				      "not a directory");
@@ -653,7 +658,7 @@
   if (grub_errno)
     goto fail;
 
-  if (!(grub_le_to_cpu16 (data->inode.mode) & 040000))
+  if ((grub_le_to_cpu16 (data->inode.mode) &0170000) != 040000)
     {
       grub_error (GRUB_ERR_BAD_FILE_TYPE, "not a directory");
       goto fail;
--------------------------------------------------------------------------
-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.41770257792

Re: ext2 find patch

[Marco Gerards]

ebik@artax.karlin.mff.cuni.cz (Tomas Ebenlendr) writes:

> The same problem was with symlinks, so the new version of patch is here.
>
> It does stat every inode (and ignore the info in direntries).
> There is also small fix in absolute symlinks (chopping the initial '/')

Thanks a lot for tracking down these problems and sending in a patch.
I noticed some problems with my GNU/Hurd ext2 filesystem as well,
similar to these.  At first I thought it was because of something
related to the Hurd, now I assume it is the same problem.

What I want to do is having a look if/how I can separate the code to
test if it is a directory/symlink, traverse the tree, follow symlinks,
etc.  Now I just duplicated some code for the 3 filesystems I
implemented.  I will change the code to use one generic set of helper
functions, or perhaps changing the interfaces.  I really hate
duplicated code, it can trigger bugs (as you see here) and it
increases binary size and it makes maintaining harder.  Tackling this
problem is very important to me.

Unfortunately I do not have the time to do this now.  I am busy with
school and some other stuff.  In some weeks I will have a look at
these more generic problems and the ext2 specific problems.

So, basically, your patch will not be ignored, it will just take quite
a while before I can properly deal with it in the way I want to. :)

Thanks,
Marco

Re: ext2 find patch

[Jeroen Dekkers]

At Tue, 01 Jun 2004 22:47:10 +0200,
Marco Gerards wrote:
> 
> ebik@artax.karlin.mff.cuni.cz (Tomas Ebenlendr) writes:
> 
> > The same problem was with symlinks, so the new version of patch is here.
> >
> > It does stat every inode (and ignore the info in direntries).
> > There is also small fix in absolute symlinks (chopping the initial '/')
> 
> Thanks a lot for tracking down these problems and sending in a patch.
> I noticed some problems with my GNU/Hurd ext2 filesystem as well,
> similar to these.  At first I thought it was because of something
> related to the Hurd, now I assume it is the same problem.

That's probably because filetypes are an ext2 option and Hurd-owned
ext2 filesystems have this disables by default because it isn't
implemented in the Hurd's ext2fs.

Jeroen Dekkers

normal vs. rescue mode commands

[Tomas Ebenlendr]

...
> - Making loaders work in normal mode.
> 
> Currently loaders only work in rescue mode.  The main thing that needs to be done 
> is that the loaders will be registered with normal mode as well.  If you want to
> do that all loaders need to register itself with normal mode and normal mode
> should scan for not yet registered normal mode modules (I think...).  As you
> might notice, I am not sure about how it needs to be done.  Hopefully Okuji
> has some ideas.

And what about enabling rescue mode commands in normal mode? (Of course
the command 'normal' should be hidden). I cannot imagine rescue command
that should be not accessible from normal mode. Now there are two
IDENTICAL functions for commands like 'unset'. (they differ only by
prototype).

If it is not good idea, what about command 'rescuecmd' which will
execute one command of rescue mode?
-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.41992053102

Re: normal vs. rescue mode commands

[Tomas Ebenlendr]

> And what about enabling rescue mode commands in normal mode? (Of course
> the command 'normal' should be hidden). I cannot imagine rescue command
> that should be not accessible from normal mode. Now there are two
> IDENTICAL functions for commands like 'unset'. (they differ only by
> prototype).

There can be then two types of modules:
    1.) do not require 'normal' - implement only rescue mode commands
    2.) require 'normal' - implement normal mode commands (no need for
    rescue mode when we have normal mode)

This looks simpler than loading 'normal' and 'loaders' in arbitrary
order.

It can be done two ways:
    - lazy - patch normal mode searching and executing command
	(I prefer this way)
    - busy - init of normal will generate command entries,
	and hook registering command in rescue mode.
	(I dislike this way because of the 'hook')
-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.41997694672

Re: normal vs. rescue mode commands

[Marco Gerards]

ebik@artax.karlin.mff.cuni.cz (Tomas Ebenlendr) writes:

>     - lazy - patch normal mode searching and executing command
> 	(I prefer this way)

That's the same as what I had in mind.  Personally I prefer this
solution.

Okuji, you told me a while ago that you wanted to think about this.
What is your opinion?

Thanks,
Marco

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Wednesday 02 June 2004 18:10, Marco Gerards wrote:
> Okuji, you told me a while ago that you wanted to think about this.
> What is your opinion?

I'm not sure if I understand your quesion correctly. But if it is about 
sharing commands between rescue mode and normal mode, I don't want to 
share them at all. Because I want to make normal mode more fancy than 
now, and rescue mode cannot be fancy due to the size limitation (on 
i386-pc).

Okuji

Re: normal vs. rescue mode commands

[M. Gerards]

Quoting "Yoshinori K. Okuji" <okuji@enbug.org>:

> On Wednesday 02 June 2004 18:10, Marco Gerards wrote:
> > Okuji, you told me a while ago that you wanted to think about this.
> > What is your opinion?
> 
> I'm not sure if I understand your quesion correctly. But if it is about 
> sharing commands between rescue mode and normal mode, I don't want to 
> share them at all. Because I want to make normal mode more fancy than 
> now, and rescue mode cannot be fancy due to the size limitation (on 
> i386-pc).

That is not really what I mean, but close.  What I was talking about is laoders.
The linux, chainloader, multiboot, etc. can be shared.  Both have different
access points I assume.

The problem is that when you load a loader should be able access it from both
normal mode and rescue mode.  An example is the chainloader and linux loader
compiled into rescue mode.  When you load normal.mod those loaders have to be 
registered with normal mode.

The best solution, it seems, is creating a list of modules that need to be 
registered with normal mode.  Or just a list of modules (all modules) that can
be scanned.  When normal mode is started the first thing it needs to do is scan
for active modules, like linux and chainloader.

--
Marco

Re: normal vs. rescue mode commands

[Tomas Ebenlendr]

> On Wednesday 02 June 2004 18:10, Marco Gerards wrote:
> > Okuji, you told me a while ago that you wanted to think about this.
> > What is your opinion?
> 
> I'm not sure if I understand your quesion correctly. But if it is about 
> sharing commands between rescue mode and normal mode, I don't want to 
> share them at all. Because I want to make normal mode more fancy than 
> now, and rescue mode cannot be fancy due to the size limitation (on 
> i386-pc).
> 
> Okuji

I think that loaders will have common code for both modes. And so there
can be wrapper (which will be in normal mode) to provide this commands
to normal mode. And the loaders themself need not to have normal mode
commands if the rescue commands (including their descriptions) will be
accessible from normal mode.

What I want is to not write "normal mode code" to module which can be
used without normal mode.

Yes there are some restrictions, for example those commands will not be
such fancy as normal mode commands. But should be commands as 'initrd'
fancy?

What I propose is provide all rescue commands to normal mode (except
command normal) if they hasn't same name as some normal mode command.

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.4224409912

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Thursday 03 June 2004 14:50, Tomas Ebenlendr wrote:
> I think that loaders will have common code for both modes. And so
> there can be wrapper (which will be in normal mode) to provide this
> commands to normal mode. And the loaders themself need not to have
> normal mode commands if the rescue commands (including their
> descriptions) will be accessible from normal mode.

That's right, as long as we can use the same loaders...

> Yes there are some restrictions, for example those commands will not
> be such fancy as normal mode commands. But should be commands as
> 'initrd' fancy?

My experience tells me that users will want to have more than expected. 
So I won't be surprised when users send feature requests that initrd 
should do something incredible.

Indeed, there is an unofficial patch for initrd, which makes an initrd 
image dynamically by adding arbitrary kernel modules at run time. This 
makes me afraid that anything possible will happen.

The difficulty in this issue is that most loaders should be identical 
between the two modes but probably not all loaders can be, due to the 
size limitation. For example, Multiboot Specification has many optional 
features now, such as VESA support. If this does not fit to rescue 
mode, we need to use different loaders for Multiboot. I guess this 
probablity is quite high.

So I'd like to propose some solutions for this:

1. Generate two versions for each loader from the same source code.

This case compiles the same source code twice to generate two different 
loaders for rescue mode and normal mode. Basically, the version for 
rescue mode would be a subset of the version for normal mode. This 
makes redundant binary code, but the maintainability is not very bad.

2. Share the same loaders if possible, and make different soure code if 
not possible.

If a loader can be shared between rescue mode and normal mode, we make 
it as a rescue mode loader and use it from normal mode as well. If this 
is not possible, we make a different loader specific for normal mode. 
My intuition is that this is quite unmaintainable, because things are 
not consistent.

3. Use only a chainloader in rescue mode. The others require normal 
mode.

This is what I thought at the beginning of this project. Because 
chainloader can be quite compact and so convenient if you have any 
other boot loader installed in your system, chainload might suffice for 
rescue purpose. In this case, we just forget sharing loaders. Only 
chainloader must be implemented for rescue mode and normal mode.

Any idea?

Okuji

Re: normal vs. rescue mode commands

[Tomas Ebenlendr]

>...

> Indeed, there is an unofficial patch for initrd, which makes an initrd 
> image dynamically by adding arbitrary kernel modules at run time. This 
> makes me afraid that anything possible will happen.

Wow, that is very nice feature :-).

>...

> 1. Generate two versions for each loader from the same source code.
> 
> This case compiles the same source code twice to generate two different 
> loaders for rescue mode and normal mode. Basically, the version for 
> rescue mode would be a subset of the version for normal mode. This 
> makes redundant binary code, but the maintainability is not very bad.

This looks like best solution for me, also the 'normal' mode loader may
depend on 'rescue' mode loader and use some of its functions. This looks
like most 'clean' way. If we want that users won't be confused by 2
modules doing the same, we can add 'automatic module load support' which
will load modules-normal_mode_extensions of loaded loaders to normal mode.

> 2. Share the same loaders if possible, and make different soure code if 
> not possible.
> 
> If a loader can be shared between rescue mode and normal mode, we make 
> it as a rescue mode loader and use it from normal mode as well. If this 
> is not possible, we make a different loader specific for normal mode. 
> My intuition is that this is quite unmaintainable, because things are 
> not consistent.

May be. I think that 'normal mode extensions' are somwhere in between
1. and 2.

> 3. Use only a chainloader in rescue mode. The others require normal 
> mode.
> 
> This is what I thought at the beginning of this project. Because 
> chainloader can be quite compact and so convenient if you have any 
> other boot loader installed in your system, chainload might suffice for 
> rescue purpose. In this case, we just forget sharing loaders. Only 
> chainloader must be implemented for rescue mode and normal mode.

Hmm, I like to boot 'rescue' kernel with 'rescue' initrd and not using
floppy or CD.


I include here the previously dicussed solution only for completness
of the list of solutions how loaders can be implemented:

4. There is also the solution wich I dislike, that is normal mode
extensions compiled in loaders. I designed interface wich implements
client/server module cooperation when modules should be loaded
independently. My opinion is that this interface does the same work,
which can do module loader, when client module depends on server module,
but more complicated way. (I don't understand binutils and module loader,
so it is done by tables of functions and indirect calls :-(. )
Also normal mode code is redundant in rescue mode, which should be as
small as possible.
-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.43038501189

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Sunday 06 June 2004 12:55, Tomas Ebenlendr wrote:
> > 1. Generate two versions for each loader from the same source code.
> >
> > This case compiles the same source code twice to generate two
> > different loaders for rescue mode and normal mode. Basically, the
> > version for rescue mode would be a subset of the version for normal
> > mode. This makes redundant binary code, but the maintainability is
> > not very bad.
>
> This looks like best solution for me, also the 'normal' mode loader
> may depend on 'rescue' mode loader and use some of its functions.
> This looks like most 'clean' way. If we want that users won't be
> confused by 2 modules doing the same, we can add 'automatic module
> load support' which will load modules-normal_mode_extensions of
> loaded loaders to normal mode.

Ok. As others seem to have no opinion, let's go in this way.

Then, how about the naming convention? We need to have a standard way to 
distinguish between normal mode loaders and rescue mode loaders by file 
names. That is why I prefixed loaders with '_'. But I don't think an 
underscore is so good.

And, at the same time, I'd like to make all filenames fit into the 
DOS-style (8.3 filenames), so that we don't need to use VFAT on FAT 
filesystems. I think this is better, because Microsoft claims that they 
have a software patent about the long filename extension... *sigh*

What do you think?

Okuji

Re: normal vs. rescue mode commands

[Jeroen Dekkers]

At Wed, 9 Jun 2004 13:19:34 +0200,
Yoshinori K. Okuji wrote:
> And, at the same time, I'd like to make all filenames fit into the 
> DOS-style (8.3 filenames), so that we don't need to use VFAT on FAT 
> filesystems. I think this is better, because Microsoft claims that they 
> have a software patent about the long filename extension... *sigh*

Well, everything is patented. You can't write much without violating
some patent. I think it's better to just ignore those patents.

Jeroen Dekkers

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Wednesday 09 June 2004 14:07, Jeroen Dekkers wrote:
> Well, everything is patented. You can't write much without violating
> some patent. I think it's better to just ignore those patents.

Not everything, but *nearly* everything. :)

In this case, however, Microsoft is too aggresive. You know, they are 
actually sending invoices to several companies. Since FSF is in US, I 
don't think we can ignore this serious problem.

Okuji

Re: normal vs. rescue mode commands

[Jeroen Dekkers]

At Wed, 9 Jun 2004 14:25:56 +0200,
Yoshinori K. Okuji wrote:
> 
> On Wednesday 09 June 2004 14:07, Jeroen Dekkers wrote:
> > Well, everything is patented. You can't write much without violating
> > some patent. I think it's better to just ignore those patents.
> 
> Not everything, but *nearly* everything. :)
> 
> In this case, however, Microsoft is too aggresive. You know, they are 
> actually sending invoices to several companies. Since FSF is in US, I 
> don't think we can ignore this serious problem.

What's does the FSF actually advice about this? I'm sure a lot of
other GNU projects violate patents.

Jeroen Dekkers

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Wednesday 09 June 2004 14:48, Jeroen Dekkers wrote:
> What's does the FSF actually advice about this?

I don't know. You can ask it yourself.

> I'm sure a lot of 
> other GNU projects violate patents.

Be specific. Otherwise, it's just a FUD.

GNU has been making effort on avoiding patents and trying to make 
alternatives. A good example is gzip. This was made due to a patent on 
compress. The FSF forces GNU maintainers not to use GIF due to the 
well-known LZW patent. If there are patent infringements in GNU 
Software, I'm very sure that RMS wants to make alternatives.

Okuji

Re: normal vs. rescue mode commands

[Jeroen Dekkers]

At Wed, 9 Jun 2004 15:12:58 +0200,
Yoshinori K. Okuji wrote:
> 
> On Wednesday 09 June 2004 14:48, Jeroen Dekkers wrote:
> > What's does the FSF actually advice about this?
> 
> I don't know. You can ask it yourself.
> 
> > I'm sure a lot of 
> > other GNU projects violate patents.
> 
> Be specific. Otherwise, it's just a FUD.
> 
> GNU has been making effort on avoiding patents and trying to make 
> alternatives. A good example is gzip. This was made due to a patent on 
> compress. The FSF forces GNU maintainers not to use GIF due to the 
> well-known LZW patent. If there are patent infringements in GNU 
> Software, I'm very sure that RMS wants to make alternatives.

Well, as we've seen, JPEG is also patented. The problem of patents is
that there are so many and most of them are very broad. But enough
about this. I hope that we can stop this nonsense becoming reality in
Europe.

I still think the 8.3 limitations for filenames is awkward. Certainly
because most people won't be using fat as their booting
partition. And the files of GRUB Legacy don't fit 8.3 either.

Jeroen Dekkers

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Wednesday 09 June 2004 15:54, Jeroen Dekkers wrote:
> Well, as we've seen, JPEG is also patented.

Does it affect the usage of JPEG in GNU? If so, let RMS know it, please.

> The problem of patents is 
> that there are so many and most of them are very broad. But enough
> about this. I hope that we can stop this nonsense becoming reality in
> Europe.

Only in EU. And, this war never end even in EU, until stupid patent laws 
are legalized.

In US and Japan, I see no hope for now.

> I still think the 8.3 limitations for filenames is awkward.

Yes. I agree.

> Certainly 
> because most people won't be using fat as their booting
> partition.

I don't agree. You think so, because you don't use embedded systems. I 
know many people use FAT when they use flash memory devices such as 
compact flash and DiskOnChip.

> And the files of GRUB Legacy don't fit 8.3 either. 

All the essential files fit:

stage1 -> 5 + 0
stage2 -> 5 + 0
menu.lst -> 4 + 3

Okuji

Re: normal vs. rescue mode commands

[Jeroen Dekkers]

At Wed, 9 Jun 2004 16:22:40 +0200,
Yoshinori K. Okuji wrote:
> 
> On Wednesday 09 June 2004 15:54, Jeroen Dekkers wrote:
> > Well, as we've seen, JPEG is also patented.
> 
> Does it affect the usage of JPEG in GNU? If so, let RMS know it, please.

I don't really know whether it's about the use or creation of
jpegs. The patent will also expire soon, probably before any
significant changes can be made.
 
> > The problem of patents is 
> > that there are so many and most of them are very broad. But enough
> > about this. I hope that we can stop this nonsense becoming reality in
> > Europe.
> 
> Only in EU. And, this war never end even in EU, until stupid patent laws 
> are legalized.

The European Parliament voted against software patents last
time. There is a good chance they will do it next time too.

> In US and Japan, I see no hope for now.

Yes, although I hear that the FTC isn't that happy with the current
patent system either.
 
> > I still think the 8.3 limitations for filenames is awkward.
> 
> Yes. I agree.
> 
> > Certainly 
> > because most people won't be using fat as their booting
> > partition.
> 
> I don't agree. You think so, because you don't use embedded systems. I 
> know many people use FAT when they use flash memory devices such as 
> compact flash and DiskOnChip.

Yes, but still I don't think that we should obfuscate the module
names. Multiboot is already 9 letters, for example.

> > And the files of GRUB Legacy don't fit 8.3 either. 
> 
> All the essential files fit:
> 
> stage1 -> 5 + 0
> stage2 -> 5 + 0
> menu.lst -> 4 + 3

Yes, but stage1.5 files don't.

Jeroen Dekkers

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Wednesday 09 June 2004 16:44, Jeroen Dekkers wrote:
> The European Parliament voted against software patents last
> time. There is a good chance they will do it next time too.

Maybe. It depends on the coming election.

> Yes, but still I don't think that we should obfuscate the module
> names. Multiboot is already 9 letters, for example.

Why are abbreviations so bad? In fact, we use "mb" as an abbreviation of 
multiboot in GRUB Legacy, but there is no problem with this.

I agree that abbreviations should be avoided for ordinary users. But the 
filenames of modules are not for ordinary users. They should be used 
only by those who know how GRUB works more or less.

The advantage of abbreviations: GRUB is compatible with all filesystems, 
including popular ones (e.g. FAT, ISO9660, MinixFS, HFS).

The disadvantage of them: Sometimes filenames do not tell you what they 
are clearly.

For me, the advantage looks much more important, since the disadvantage 
can be overcome with a good documentation.

> > All the essential files fit:
> >
> > stage1 -> 5 + 0
> > stage2 -> 5 + 0
> > menu.lst -> 4 + 3
>
> Yes, but stage1.5 files don't.

So?

Okuji

Re: normal vs. rescue mode commands

[Tomas Ebenlendr]

> 
> Ok. As others seem to have no opinion, let's go in this way.
> 
> Then, how about the naming convention? We need to have a standard way to 
> distinguish between normal mode loaders and rescue mode loaders by file 
> names. That is why I prefixed loaders with '_'. But I don't think an 
> underscore is so good.
> 
> And, at the same time, I'd like to make all filenames fit into the 
> DOS-style (8.3 filenames), so that we don't need to use VFAT on FAT 
> filesystems. I think this is better, because Microsoft claims that they 
> have a software patent about the long filename extension... *sigh*
> 
> What do you think?
> 
> Okuji
> 

Moreover we can use iso9660 level 1 naming standard (8.3, restricted alphabet).
This will let us boot from CD's without Rockridge/Joilet (Once I tried
to burn grub in Win and I failed because there was no rr).

here are some proposals

loader_r.mod for rescue mode 
loader_n.mod for normal mode

or

loader.mod for rescue mode
loader_n.mod for normal mode
and normal.mod will try to load '_n' variant of each loaded module (and
  normal mode insmod will do the same)

I like '_x' because it looks like 'x' variant of module.

PS.: Somebody told me, that M$ has patent about double click.
-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.43877453957

Re: normal vs. rescue mode commands

[Tomas Ebenlendr]

> 
> I like '_x' because it looks like 'x' variant of module.
> 

Oh I forgot, I like suffixes because of 'tab' completition:
I want to load 'linux', and then I want to choose which 'linux'

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.43880973614

Re: normal vs. rescue mode commands

[Yoshinori K. Okuji]

On Wednesday 02 June 2004 16:43, Tomas Ebenlendr wrote:
> And what about enabling rescue mode commands in normal mode?

I don't think it would be very useful. Even the command 'unset' will be 
implemented in a different way, say, to support set/unset hooks for 
special variables.

> If it is not good idea, what about command 'rescuecmd' which will
> execute one command of rescue mode?

Why do you want this?

Okuji

Re: ext2 find patch

[Marco Gerards]

ebik@artax.karlin.mff.cuni.cz (Tomas Ebenlendr) writes:

> The same problem was with symlinks, so the new version of patch is here.
>
> It does stat every inode (and ignore the info in direntries).
> There is also small fix in absolute symlinks (chopping the initial '/')

I've checked in your patch, after making some minor changes:

2004-06-27  Tomas Ebenlendr  <ebik@ucw.cz>

	* fs/ext2.c (FILETYPE_INO_MASK, FILETYPE_INO_DIRECTORY)
	(FILETYPE_INO_SYMLINK): New macros.
	(grub_ext2_find_file): Check if the node is a directory using the
	inode stat information instead of using the filetype in the
	dirent.  Exclude the first character of an absolute symlink.
	(grub_ext2_dir): Mask out the filetype part of the mode member of
	the inode.

I do not know why you moved the code to read the inode around.  I
didn't check that in.  Why is that required?

Please test if this works for you now.  It fixed my problem.

Thanks,
Marco