All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: How can I use grub_getcrc32 in fs module
Date: Sun, 14 Mar 2010 13:32:46 +0100	[thread overview]
Message-ID: <4B9CD76E.8020102@gmail.com> (raw)
In-Reply-To: <8763545kvt.wl%jir@sekiba.com>

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

Jiro SEKIBA wrote:
>> Filesystem modules are often size-constrained. So we skip the
>> consistency checks unless they are inherent part of filesystem operation.
>> If filesystem is corrupted there isn't much we can do other than hope
>> that boot-related files aren't affected. GRUB itself never writes to fs
>> metadata so it won't lead to any additional corruption
>>     
>
> Ah, I see.  Ok, then we may skip checking super block crc.
>   
Skipping only part of crc checks doesn't bring anything.
> However, becuase of nature of nilfs2, a log file system,
> I need to roll forward the logs to find the latest log
> in case that super block does not point appropriate latest log
> on unclean unmounting.
>
> In the forwarding process, log is verified by crc.
>
>   
In this case ok. Can you make tests and compare the size with either
using lib/crc.c or CRC32 from crypto framework? This is something that
would justify keeping lib/crc.c despite my previous plans on its removal
if the difference is significant.
>>> I added lib/crc.c in SOURCES in common.rmk for the fs module.
>>> It looks OK to compile the target fs module.
>>> However I got following link error for grub-setup and grub-probe.
>>>
>>> grub_setup-fs_nilfs2.o: In function `grub_nilfs2_valid_sb':
>>> nilfs2.c:(.text+0xe29): undefined reference to `grub_getcrc32'
>>> nilfs2.c:(.text+0xe47): undefined reference to `grub_getcrc32'
>>> nilfs2.c:(.text+0xe7e): undefined reference to `grub_getcrc32'
>>> collect2: ld returned 1 exit status
>>>
>>> I was trying to specify lib/crc.c in grub_setup_SOURCES, but got same result.
>>>
>>>   
>>>       
>> Stupid question: have you rerun ./autogen.sh ?
>>     
>
> Yes, I did.  I should have mentioned.
> What I did is
>
> sh autogen.sh
> make clean;./configure;make
>
>   
May I have a look at this part of the patch?


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

  reply	other threads:[~2010-03-14 12:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-10 12:23 How can I use grub_getcrc32 in fs module Jiro SEKIBA
2010-03-10 13:05 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-03-10 14:09   ` Jiro SEKIBA
2010-03-14 12:32     ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2010-03-15 10:03       ` Jiro SEKIBA
2010-03-15 10:52         ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-03-16  7:22           ` Jiro SEKIBA

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=4B9CD76E.8020102@gmail.com \
    --to=phcoder@gmail.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.