Re: Reiser4 support in GNU GRUB...

[Yury Umanets]

Yoshinori K. Okuji wrote:

> At Thu, 03 Apr 2003 15:10:22 +0400,
> Yury Umanets wrote:
>  
>
> > Some time ago I've written the letter to address@hidden about reiser4 
> > support in GNU GRUB and adding memory management to it. As I still have 
> > not an answer, I write it one more time. And I hope to receive it this time.
> >    
>
> I'm sorry. I missed your previous mail.

>  
>
> > Reiser4 team is interested in adding reiser4 support to GNU GRUB. And it 
> > can be done by means of using our static libreiser4, built in stand 
> > alone mode, that is, without libc, gcc built-ins and without features 
> > which are not needed for GRUB like file creating/writing, repair stuff, 
> > etc.
> >    

> Is that easier than modifying our code to support Reiser4?
In general, we have foreseen possible difficulties like device access, 
exceptions, memory allocation and libc independance. We have so called 
libaal (application abstraction library) to solve all these things. And 
our libreiser4 uses libaal for working fine in any enviromnent (usual 
userspace applications: our reiser4 utils, GNU Parted with its device 
access policies; "stand alone" mode like GRUB works in, etc)

For example, library it self do not operates on usual file descriptor, 
but preffer to use simple device abstraction layer which has open(), 
close(), read() and write() methods in its interface.

So, currently we need only to solve the problem I described it in my 
email and namely FSYS_BUF corruption.

>  
>
> > And now the problem is that, we cannot use FSYS_BUF for memory manager, 
> > because it is used by all fs GRUB supports them and as they are not 
> > aware about the memory manager, they work with FSYS_BUF as with 
> > dedicated to them raw data array and corrupt it.
> >    

> Why is it a problem, although GRUB 0.9x doesn't support opening
> multiple files at a time?

> attempt_mount is always called before
> opening a file, so you can initialize FSYS_BUF to a known state in a
> mount function.
Suppose FSYS_BUF contains few memory chunks like the following:

[ state=free, len=23056 ], [ state=occupied, len=4096 ] ... [ stat=free, 
len=4096 ]

All them was initialized in the time of first reiser4_mount() running. 
And they contain instances of the allocated reiser4 objects like opened 
root directory, opened filesystem, tree cache, etc. Before any reiser4 
function takes control again, this FSYS_BUF will be corrupted for 
instance by ext2_mount() function which will be called from attempt_mount().

Simple working log:

root (hd0,1)

Leads to calling attempt_mount() and it calls ext2_mount(), and if it 
fails calls xfs_mount() and so on. Suppose control comes to 
reiser4_mount(). reiser4_mount() opens reiser4 filesystem on current 
device and returns success code.

cat /linux/COPYING

Leads to calling attempt_mount() again which calls ext2_mount() and 
friends and they corrupt FSYS_BUF. And when control comes to 
reiser4_mount(), reiser4_dir() and reiser4_read(), FSYS_BUF has been 
corrupted yet.

So from my standpoint there are few not good things:

(1) Between successfull somefs_mount() and for instance somefs_dir() 
also will be called yet_another_fs_mount().
(2) There is not duality in calling somefs_mount() and somefs_close(). 
Why somefs_mount() is called again without somefs_close() being called 
before?

>  
>
> > In boot time everything probably will be okay, as GRUB will use only one 
> > fs-implemntation and namely root partition uses it, say reiser4. But as 
> > "memory manager tack" exists in GRUB's TODO list, probably it is time to 
> > implement it?
> >    

> It has already been implemented for GRUB 2 (aka PUPA). It will never
> be implemented for GRUB 1.
Can it be obtained from a CVS?

> Thanks,
> Okuji
>
>
>  
Bye

--
Yury Umanets