From: kai@gnukai.com (Kai Meyer)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Understanding memcpy
Date: Thu, 20 Oct 2011 09:40:29 -0600 [thread overview]
Message-ID: <4EA040ED.5020105@gnukai.com> (raw)
In-Reply-To: <CALJfu6NM4dfkKxeKgttqUnq3u=F+eHqds7ajh5CzshAH3nvH_w@mail.gmail.com>
Thanks for catching that :) I knew it would be something simple.
On 10/19/2011 10:00 PM, rohan puri wrote:
>
>
> On Thu, Oct 20, 2011 at 3:04 AM, Kai Meyer <kai@gnukai.com
> <mailto:kai@gnukai.com>> wrote:
>
> I'm trying to poke around an ext4 file system. I can submit a bio for
> the correct block, and read in what seems to be the correct
> information,
> but when I try to memcpy my char *buffer to a reference to a
> struct I've
> made, it just doesn't seem to work. The relevant code looks like this:
>
> typedef struct ext2_superblock {
> /* 00-03 */ uint32_t e2sb_inode_count;
> /* 04-07 */ uint32_t e2sb_block_count;
> /* 08-11 */ uint32_t e2sb_blocks_reserved;
> /* 12-15 */ uint32_t e2sb_unallocated_blocks;
> /* 16-19 */ uint32_t e2sb_unallocated_inodes;
> /* 20-23 */ uint32_t e2sb_sb_block;
> /* 24-27 */ uint32_t e2sb_log_block_size;
> /* 28-31 */ uint32_t e2sb_log_fragment_size;
> /* 32-35 */ uint32_t e2sb_num_blocks_per_group;
> /* 36-39 */ uint32_t e2sb_num_frag_per_group;
> /* 40-43 */ uint32_t e2sb_num_inodes_per_group;
> /* 44-47 */ uint32_t e2sb_last_mount_time;
> /* 48-51 */ uint32_t e2sb_last_written_time;
> /* 52-53 */ uint16_t e2sb_num_mounted;
> /* 54-55 */ uint16_t e2sb_num_allowed_mounts;
> /* 56-57 */ uint16_t e2sb_signature;
> /* 58-59 */ uint16_t e2sb_fs_state;
> /* 60-61 */ uint16_t e2sb_error_action;
> /* 62-63 */ uint16_t e2sb_ver_minor;
> /* 64-67 */ uint32_t e2sb_last_check;
> /* 68-71 */ uint32_t e2sb_time_between_checks;
> /* 72-75 */ uint32_t e2sb_os_id;
> /* 76-79 */ uint32_t e2sb_ver_major;
> /* 80-81 */ uint16_t e2sb_uid;
> /* 82-83 */ uint16_t e2sb_gid;
> } e2sb;
>
>
> char *buffer;
> uint32_t *pointer;
> e2sb sb;
> buffer = __bio_kmap_atomic(bio, 0, KM_USER0);
> pointer = (uint32_t *)buffer;
> printk(KERN_DEBUG "sizeof pbd->sb %lu\n", sizeof(bpd->sb));
> printk(KERN_DEBUG "Inode Count: %u\n", pointer[0]); /* Works! */
> printk(KERN_DEBUG "Block Count: %u\n", pointer[1]); /* Works! */
> printk(KERN_DEBUG "Block Reserved: %u\n", pointer[2]); /* Works! */
> printk(KERN_DEBUG "Unallocated blocks: %u\n", pointer[3]); /*
> Works! */
> printk(KERN_DEBUG "Unallocated inodes: %u\n", pointer[4]); /*
> Works! */
> memcpy(buffer, &sb, sizeof(sb));
>
> This should be : -
> memcpy(&sb, buffer, sizeof(sb));
>
> __bio_kunmap_atomic(bio, KM_USER0);
> printk(KERN_DEBUG "e2sb_debug: Total number of inodes in file system
> %u\n", sb->e2sb_inode_count);/* Doesn't work! */
> printk(KERN_DEBUG "e2sb_debug: Total number of blocks in file
> system%u\n", sb->e2sb_block_count); /* Doesn't work! */
>
> My code is actually much more verbose. The values I get from indexing
> into pointer are correct, and match what I get from dumpe2fs. The
> values
> I get from the e2sb struct are not. They are usually 0. I would
> imagine
> that memcpy is the fastest way to copy data from buffer instead of
> casting the pointer to something else, and using array indexing to get
> the values.
>
> I struggled to find where ext4 actually does this, so I'm making
> this up
> as I go along. Any thing that you see that I should be doing a
> different
> way that isn't actually part of my question is welcome too.
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> <mailto:Kernelnewbies@kernelnewbies.org>
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> Regards,
> Rohan Puri
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20111020/5980ab33/attachment.html
next prev parent reply other threads:[~2011-10-20 15:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-17 20:04 How can I test if a physical address is already mapped or not StephanT
2011-10-18 5:52 ` Rajat Sharma
2011-10-18 17:23 ` StephanT
2011-10-18 20:47 ` Jeff Haran
2011-10-18 20:58 ` StephanT
2011-10-18 21:16 ` Jeff Haran
2011-10-19 0:28 ` StephanT
2011-10-19 0:46 ` Jeff Haran
2011-10-19 1:01 ` StephanT
2011-10-19 1:16 ` Jeff Haran
2011-10-19 5:48 ` Rajat Sharma
2011-10-19 17:10 ` StephanT
2011-10-19 16:04 ` Trouble removing character device Kai Meyer
2011-10-19 20:18 ` Daniel Baluta
2011-10-19 20:55 ` Kai Meyer
2011-10-19 21:34 ` Understanding memcpy Kai Meyer
2011-10-20 4:00 ` rohan puri
2011-10-20 15:40 ` Kai Meyer [this message]
2011-10-20 3:47 ` Trouble removing character device rohan puri
2011-10-20 15:41 ` Kai Meyer
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=4EA040ED.5020105@gnukai.com \
--to=kai@gnukai.com \
--cc=kernelnewbies@lists.kernelnewbies.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.