Re: Reiser4 and GRUB...

[Yury Umanets]

Jochen Hoenicke wrote:

> On Sunday 25 May 2003 20:23, Yoshinori K. Okuji wrote:
>  
>
> > At Sat, 24 May 2003 18:54:23 +0400,
> > Yury Umanets wrote:
> >    
> >
> > > Thanks for answer. I thought before, that address@hidden list is not 
> > > friendly one.  But I was wrong :)
> > >      
> > I think you were right. That time, Jochen was responsible for ReiserFS
> > support, so I thought it would be better to keep things preferable for
> > him. He liked to use our own implementation. However, I haven't heard
> > from him anything recently, so I now think it would be better to
> > change things for a new active developer (i.e. you).
> >    

> As my name is mentioned, I think it is time to say something, too :)
> Yes it's true, I have been busy with other things and haven't found
> the time to read the bug-grub mailing lists.  Actually, I hardly found
> the time to scan the subjects, as the amounts of mail seems to have
> increased dramatically. I may have missed many mails that fall in my
> realm.

> Back to the topic: IMHO maintaining a file-system driver in grub is
> not too much work.  This is because file-systems changes are
> introduced very conservatively, once the file-system is in use.  There
> was one bigger change for the reiserfs-2 to 3 transition and one small
> change because a super block field had finally a meaning that was
> different from the one originally planned.  The other changes were
> mainly bug fixing in my own code.

> This is, of course, just my opinion and I don't want to tell Yury how
> to do it (this is Okuji's Job :).  I haven't followed the reiserfs
> development recently and don't know much about reiserfs-4.  So it's
> okay that Yury takes over maintenance of reiserfs.
This is okay :) One day I will unable to devote a lot of time to grub. 
New active developer will be involved to grub developing and supporting. 
And so on.

> As for squeezing the size of libreiser: You don't need any code that
> allocates blocks or writes to the file-system, so you can omit all the
> rebalancing tree code, block allocation algorithm, block bitmap
> parsing and so on.  If you have done this already, forget this comment :)
This is done already :) We have so called "device abstraction layer", 
filesystem code in library interacts with it. And its real calls (device 
access) may be reimplemented and in the case of GRUB its implementation 
uses devread() and friends for actual read.

Speaking about size of the stage1_5, I see three main big pieces of code:

(1) Plugins management (plugin factory, pluign structs, etc).
(2) Extents code. For instance, extent40_read() took more then 560 bytes 
of code in result binary built with all possibe -fallign-* and -Os and 
with debug on gcc-3.3.
(3) Directory items code.

Also we have own mem* and str* functions, and some of them are almost 
the same as in GRUB.

>  Jochen
>
>  
Thanks :)

--
Yury Umanets
"We're flying high, we're watching the world passes by..."