Couple questions regarding ramdisk/initrd

127 views
Skip to first unread message

Hypo Turtle

unread,
Feb 18, 2016, 4:48:57 PM2/18/16
to Android-x86
OK if anyone has the time to run through a few things before I start poking around.

1. Can the ramdisk.img and initrd.img not be combined into one; i.e. rename init in ramdisk to init.android combine files and in initrd init change line to
exec ${SWITCH:-switch_root} /android /init.android,  and don't zcat|cpio ramdisk...

Or is there something I'm over looking or is it just to keep the built process simple (keeping ramdisk.img essentially stock Android)

2. Regarding the modules: would I be right in thinking the important path is /lib/modules/`uname -r`/*

And if so where is that set? and could an additional ext4 .img containing modules (or several sets of modules for testing); be mounted to /lib (in place of the symlink to /system/lib) and used.

Chih-Wei Huang

unread,
Feb 19, 2016, 10:56:47 PM2/19/16
to Android-x86
2016-02-19 5:48 GMT+08:00 Hypo Turtle <hypot...@gmail.com>:
> OK if anyone has the time to run through a few things before I start poking
> around.
>
> 1. Can the ramdisk.img and initrd.img not be combined into one; i.e. rename
> init in ramdisk to init.android combine files and in initrd init change line
> to
> exec ${SWITCH:-switch_root} /android /init.android, and don't zcat|cpio
> ramdisk...

I think you meant "can ramdisk.img and initrd.img be combined into one"?
Surely it can.

> Or is there something I'm over looking or is it just to keep the built
> process simple (keeping ramdisk.img essentially stock Android)

Exactly. You've found the answer.

> 2. Regarding the modules: would I be right in thinking the important path is
> /lib/modules/`uname -r`/*
>
> And if so where is that set? and could an additional ext4 .img containing
> modules (or several sets of modules for testing); be mounted to /lib (in
> place of the symlink to /system/lib) and used.

Your question is too vague.
I can just say anything is possible.

Modules could be put anywhere provided
the module loading utility knows where to find them.

/lib/modules/`uname -r`/* is the traditional path
to put modules that modprobe uses.
Android-x86 just follows the convention, but
it's definitely not a requirement.

Note AOSP doesn't have modprobe.
(in fact AOSP discourage to use linux modules)
The modprobe used in Android-x86 image
is ported by ourselves.
Also note currently Android-x86 provides two alternate
implementations of modprobe.
One from busybox and another from the hacking
of ueventd. The latter is the default and
both work almost the same.


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

Hypo Turtle

unread,
Feb 20, 2016, 8:46:01 AM2/20/16
to Android-x86
Yea, that's what I meant, I meant it as a question.

Thanks for the clarification, somehow I missed the modprobe location when I was looking for it, when it is right there in your face.

Do you forsee any issues having just a /lib/modules/* folder? - as opposed to a symlink to /system/lib; supposedly for backwards compatibility, but I think redundant with LP/MM

Chih-Wei Huang

unread,
Feb 21, 2016, 10:48:07 PM2/21/16
to Android-x86
2016-02-20 21:46 GMT+08:00 Hypo Turtle <hypot...@gmail.com>:
> Yea, that's what I meant, I meant it as a question.
>
> Thanks for the clarification, somehow I missed the modprobe location when I
> was looking for it, when it is right there in your face.
>
> Do you forsee any issues having just a /lib/modules/* folder? - as opposed
> to a symlink to /system/lib; supposedly for backwards compatibility, but I
> think redundant with LP/MM

/lib and /system are different filesystems.
/lib is in the root tmpfs filesystem which
is created via ramdisk.img.
If you want to put all modules into /lib
instead of symlink to /system/lib,
it will bloat your ramdisk.img.
Surely you can do it if you don't care that.
Note /system/lib/modules is about 90MB
for kernel 4.4 currently.

Of course you may invent other ways to
conquer the problem.
Using symlink to /system is the simplest
and probably best solution I can think.

Hypo Turtle

unread,
Feb 22, 2016, 4:48:18 PM2/22/16
to Android-x86
I was aware of that, was intending more for /lib to be a mountpoint for an additional img

Starting to think though that (/system)/vendor might be more useful to take over, especially if used with sfs system partitions as prop's and stuff are already called from there, and sylink back to /lib

Reply all
Reply to author
Forward
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
0 new messages