Re: My effort to learn Linux kernel development
you have to understand more from a design perspective, also have to understand what problem is kernel addressing and its design. Dwelling into code directly won't help, you may lose interest after some time. It's good to start with the process. memory and file management. One more thing, you have to put it in practise otherwise, you will soon forget what you learnt. Krishna. On Wed, Jul 21, 2021 at 7:32 PM Amit Kumar wrote: > Hi All, > > I am just here to inform that I am trying to learn Linux kernel > development. If someone wants to follow me, so that he may also learn > with me. > > https://freeark1blog.blogspot.com/2021/07/my-aspiration-go-live.html > https://freeark1blog.blogspot.com/2021/07/the-minimal-c-program.html > https://twitter.com/freeark1 > > I'll send update on this mail thread. > > Please, stay tuned. > > Regards, > Amit Kumar > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Interested in kernel development
Hi, Welcome to learn and explore Linux with wikibook https://en.wikibooks.org/wiki/The_Linux_Kernel . Dear Kernelnewbies maintanter, would you like to add the link to https://kernelnewbies.org/Documents ? Regards, Costa On Thu, 22 Jul 2021 at 03:21, Amit Kumar wrote: > > Hi Athul, > I think people find learning kernel development difficult due to the > following reasons, > I) Lack of understanding about the underlying hardware. > II) In the Linux kernel, some features are used which is specific to > the GCC toolchain. > III) There is also a good amount of assembly is being used which in > turn also needs the underlying hardware knowledge. > III) Last but not less important, An operating system does all its > tasks by itself. It runs in a freestanding environment. So we need the > patience to learn every aspect of an operating system. > > My next article which completes the minimal C program is coming soon. > Please, stay tuned. > > Regards, > Amit Kumar > https://twitter.com/freeark1 > > On Wed, Jul 21, 2021 at 10:27 PM Athul Joy wrote: > > > > Hi Amit, > > I am Athul Joy. I am a software developer. I have seen your mail on the > > Kernelnewbies mailing list. I have similar interests as you about learning > > more about the Linux kernel. I have tried to put some effort to learn more > > about the Linux kernel but didn't go well. I would like to follow along > > with you. I hope you could help me. > > Sincerely, > > Athul Joy > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Constantine Shulyupin ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: My effort to learn Linux kernel development
Hi All, https://freeark1blog.blogspot.com/2021/07/the-minimal-c-program-continued.html On Wed, Jul 21, 2021 at 7:31 PM Amit Kumar wrote: > > Hi All, > > I am just here to inform that I am trying to learn Linux kernel > development. If someone wants to follow me, so that he may also learn > with me. > > https://freeark1blog.blogspot.com/2021/07/my-aspiration-go-live.html > https://freeark1blog.blogspot.com/2021/07/the-minimal-c-program.html > https://twitter.com/freeark1 > > I'll send update on this mail thread. > > Please, stay tuned. > > Regards, > Amit Kumar > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Interested in kernel development
Hi Athul, I think people find learning kernel development difficult due to the following reasons, I) Lack of understanding about the underlying hardware. II) In the Linux kernel, some features are used which is specific to the GCC toolchain. III) There is also a good amount of assembly is being used which in turn also needs the underlying hardware knowledge. III) Last but not less important, An operating system does all its tasks by itself. It runs in a freestanding environment. So we need the patience to learn every aspect of an operating system. My next article which completes the minimal C program is coming soon. Please, stay tuned. Regards, Amit Kumar https://twitter.com/freeark1 On Wed, Jul 21, 2021 at 10:27 PM Athul Joy wrote: > > Hi Amit, > I am Athul Joy. I am a software developer. I have seen your mail on the > Kernelnewbies mailing list. I have similar interests as you about learning > more about the Linux kernel. I have tried to put some effort to learn more > about the Linux kernel but didn't go well. I would like to follow along with > you. I hope you could help me. > Sincerely, > Athul Joy ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: MTD: How to get actual image size from MTD partition
- Ursprüngliche Mail - >> But let me advertise ubiblock a second time. > Sorry, I could not understand about the ubiblock request. Is it > possible to elaborate little more ? > We are already using squashfs on top of our UBI volumes (including > rootfs mounting). > This is the kernel command line we pass: > rootfstype=squashfs root=/dev/mtdblock44 ubi.mtd=40,0,30 > And CONFIG_MTD_UBI_BLOCK=y is already enabled in our kernel. > Do we need to do something different for ubiblock ? From that command line I understand that you are *not* using squashfs on top of UBI. You use mtdblock. ubiblock is a mechanism to turn an UBI volume into a read-only block device. See: http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock >> If you place your squashfs on a UBI static volume, UBI knows the exact length >> and you can checksum it >> more easily. > Yes, we use squashfs on UBI volumes, but our volume type is still dynamic. > Also, you said, UBI knows the exact length, you mean the whole image length ? > How can we get this length at runtime ? You need a static volume for that. If you update a static volume the length is known by UBI. > Also, how can we get the checksum of the entire UBI volume content > (ignoring the erased/empty/bad block content) ? Just read from the volume. /dev/ubiX_Y. > Or, you mean to say, the whole checksum logic is in-built inside the > UBI layer and users don't need to worry about the integrity at all ? Static volumes have a crc32 checksum over the whole content. Of course this offers no cryptographic integrity. See: http://www.linux-mtd.infradead.org/doc/ubi.html#L_overview Thanks, //richard ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
On Wed, 21 Jul 2021, Pintu Agarwal wrote: > On Tue, 20 Jul 2021 at 17:12, Mikulas Patocka wrote: > > > > Hi > > > > Try to set up dm-verity with block size 512 bytes. > > > > I don't know what block size does squashfs use, but if the filesystem > > block size is smaller than dm-verity block size, it doesn't work. > > > Okay thank you so much for this clue, > It seems we are using 65536 as the squashfs block size: 65536 is the compression block size - it is unrelated to I/O block size. There's a config option SQUASHFS_4K_DEVBLK_SIZE. The documentation says that it uses by default 1K block size and if you enable this option, it uses 4K block size. So, try to set it. Or try to reduce dm-verity block size down to 1K. > ==> mksquashfs [...] - comp xz -Xdict-size 32K -noI -Xbcj arm -b 65536 > -processors 1 > > But for dm-verity we are giving block size of 4096 > ==> [0.00] Kernel command line:[..] verity="96160 12020 > d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 0 " > rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 [...] > root=/dev/dm-0 dm="system none ro,0 96160 verity 1 /dev/mtdblock34 > /dev/mtdblock39 4096 4096 12020 8 sha256 > d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7" > > Now, we are checking by giving squashfs block size also as 4096 > > In case, if this does not work, what else could be the other option ? > Can we try with initramfs approach ? Yes - you can try initramfs. Mikulas > Thanks, > Pintu > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
Hi Try to set up dm-verity with block size 512 bytes. I don't know what block size does squashfs use, but if the filesystem block size is smaller than dm-verity block size, it doesn't work. Mikulas On Tue, 20 Jul 2021, Pintu Agarwal wrote: > Hi, > > Our ARM32 Linux embedded system consists of these: > * Linux Kernel: 4.14 > * Processor: Qualcomm Arm32 Cortex-A7 > * Storage: NAND 512MB > * Platform: Simple busybox > * Filesystem: UBIFS, Squashfs > * Consists of nand raw partitions, squashfs ubi volumes. > > My requirement: > We wanted to use dm-verity at boot time to check the integrity of > squashfs-rootfs before mounting. > > Problem: > dm-0 is not able to locate and mount the squash fs rootfs block. > The same approach is working when emulating with ext4 but fails with squashfs. > > Logs: > [] > [0.00] Kernel command line: [...] verity="96160 12020 > d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 0 " > rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 [...] > root=/dev/dm-0 dm="system none ro,0 96160 verity 1 /dev/mtdblock34 > /dev/mtdblock39 4096 4096 12020 8 sha256 > d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7" > [] > [4.693620] vreg_conn_pa: disa▒[4.700662] md: Skipping > autodetection of RAID arrays. (raid=autodetect will force) > [4.700713] device-mapper: init: attempting early device configuration. > [4.708224] device-mapper: init: adding target '0 96160 verity 1 > /dev/mtdblock34 /dev/mtdblock39 4096 4096 12020 8 sha256 > d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7' > [4.714979] device-mapper: verity: sha256 using implementation > "sha256-generic" > [4.737808] device-mapper: init: dm-0 is ready > [] > [5.278103] No filesystem could mount root, tried: > [5.278107] squashfs > [5.280477] > [5.287627] Kernel panic - not syncing: VFS: Unable to mount root > fs on unknown-block(253,0) > [...] > > Not sure, why is it still locating block "253" here which seems like a > MAJOR number ? > > Working logs on ext4: > [] > [4.529822] v▒[4.534035] md: Skipping autodetection of RAID > arrays. (raid=autodetect will force) > [4.534087] device-mapper: init: attempting early device configuration. > [4.550316] device-mapper: init: adding target '0 384440 verity 1 > /dev/ubiblock0_0 /dev/ubiblock0_0 4096 4096 48055 48063 sha256 > a02e0c13afb31e99b999c64aae6f4644c24addbc58db5689902cc5ba0be2d15b > aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7 10 > restart_on_corruption ignore_zero_blocks use_fec_from_device > /dev/ubiblock0_0 fec_roots 2 fec_blocks 48443 fec_start 48443' > [4.572215] device-mapper: verity: sha256 using implementation > "sha256-generic" > [4.610692] device-mapper: init: dm-0 is ready > [4.720174] EXT4-fs (dm-0): mounted filesystem with ordered data > mode. Opts: (null) > [4.720438] VFS: Mounted root (ext4 filesystem) readonly on device 253:0. > [4.737256] devtmpfs: mounted > [] > > Questions: > a) Is dm-verity supposed to work on squashfs block devices ? > b) Are there any known issues with dm-verity on Kernel 4.14 ? > c) Are there any patches that we are missing ? > > > Thanks, > Pintu > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
On Wed, 21 Jul 2021 at 22:40, Mikulas Patocka wrote: > > > > > > Try to set up dm-verity with block size 512 bytes. > > > > > > I don't know what block size does squashfs use, but if the filesystem > > > block size is smaller than dm-verity block size, it doesn't work. > > > > > Okay thank you so much for this clue, > > It seems we are using 65536 as the squashfs block size: > > 65536 is the compression block size - it is unrelated to I/O block size. > > There's a config option SQUASHFS_4K_DEVBLK_SIZE. The documentation says > that it uses by default 1K block size and if you enable this option, it > uses 4K block size. > Okay it seems this config is set in our case: CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y So, with this the squashfs and dm-verity block size exactly matches (4K) > So, try to set it. Or try to reduce dm-verity block size down to 1K. > Okay we are trying this. Thank you so much!! Regards, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Kernel 4.14: Using dm-verity with squashfs rootfs - mounting issue
On Tue, 20 Jul 2021 at 17:12, Mikulas Patocka wrote: > > Hi > > Try to set up dm-verity with block size 512 bytes. > > I don't know what block size does squashfs use, but if the filesystem > block size is smaller than dm-verity block size, it doesn't work. > Okay thank you so much for this clue, It seems we are using 65536 as the squashfs block size: ==> mksquashfs [...] - comp xz -Xdict-size 32K -noI -Xbcj arm -b 65536 -processors 1 But for dm-verity we are giving block size of 4096 ==> [0.00] Kernel command line:[..] verity="96160 12020 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 0 " rootfstype=squashfs root=/dev/mtdblock34 ubi.mtd=30,0,30 [...] root=/dev/dm-0 dm="system none ro,0 96160 verity 1 /dev/mtdblock34 /dev/mtdblock39 4096 4096 12020 8 sha256 d7b8a7d0c01b9aec888930841313a81603a50a2a7be44631c4c813197a50d681 aee087a5be3b982978c923f566a94613496b417f2af592639bc80d141e34dfe7" Now, we are checking by giving squashfs block size also as 4096 In case, if this does not work, what else could be the other option ? Can we try with initramfs approach ? Thanks, Pintu ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
My effort to learn Linux kernel development
Hi All, I am just here to inform that I am trying to learn Linux kernel development. If someone wants to follow me, so that he may also learn with me. https://freeark1blog.blogspot.com/2021/07/my-aspiration-go-live.html https://freeark1blog.blogspot.com/2021/07/the-minimal-c-program.html https://twitter.com/freeark1 I'll send update on this mail thread. Please, stay tuned. Regards, Amit Kumar ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
