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 [EMAIL PROTECTED] 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 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.
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 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.
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 :)
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.
Thanks :)
Jochen
-- Yury Umanets "We're flying high, we're watching the world passes by..."
_______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub
