[Replicant] libsamsung-ipc on xmm6160 and ste m5730

[Jonathan Bakker]

Hi Denis,

On 2020-03-10 9:44 p.m., Denis 'GNUtoo' Carikli wrote:
> Hi again,
> The GT-I9100 finally arrived in my mailbox. However I probably did some
> mistakes trying to install my Replicant build on it, and the
> installation probably fails because it cannot mount system.
> 
> Do you know if there is some documentation on how LVM is used on that
> device, and how to recover when the partitions content are messed up?
> 
> By the way is it LVM1 or LVM2?
> 

I've never personally tried to install Replicant as I got my i9000 relatively recently, so I can't overly help here.

The best way to recover is to use heimdall to return to stock and try again.

The LVM partitions are setup by the updater.sh (https://git.replicant.us/replicant/device_samsung_aries-common/tree/updater.sh)
which is run in the updater-script when installing the zip.  Note that on install from stock (BML partitions from Samsung)
it does some odd stuff, such as writing the kernel and then rebooting, before it is then completed (now with MTD partitions)
and the LVM is setup.

Because there's no separate recovery, there's also a first-stage initramfs in the kernel at
https://git.replicant.us/replicant/kernel_samsung_aries/tree/usr, notably the decision
on going to recovery/main boot and the LVM setup in https://git.replicant.us/replicant/kernel_samsung_aries/tree/usr/galaxysmtd_initramfs_files

I'm not sure if it's LVM1 or LVM2, I believe it is based on the instructions found at
https://forum.xda-developers.com/nexus-s/general/howto-partitioning-nexus-s-using-lvm-t1656794

Assuming this theory is correct, it's LVM2 as the source pointed to there is
https://github.com/steven676/android-lvm-mod

> Right now I've a hard time predicting when work on libsamsung-ipc is
> done. I'm also involved in upstreaming patches in several other
> projects, and I'll get more time when this will be done.
> 
> For libsamsung-ipc I tend to do the work in burst as the code to change
> is very similar, so it gains a lot of time doing similar things one
> after the other, but at some point I have to stop and wait for the next
> burst because the code is too similar and it becomes too error prone,
> hence the importance of code review too.
> 
> I've found a way to catch more mistakes but I didn't find a way to
> apply it to C code yet: using a rendering that is different from what
> you work on (like a pdf rendering when you work on the TeX version)
> helps spotting more issues as my brain doesn't tend to skip the things
> it skips when staring at similar code for hours.
> 
> I also do understand way more the point of good code style as it helps
> here too.

Ok, fair enough.  I think I'll hold off posting the patches for now and maybe have a look at porting
the interface to forkbomb's mainline kernel driver.  No sense in doing things only to have to
modify them later.

Is there are a consistent coding style for Replicant projects?

> 
> Denis.
> 
Jonathan