[Buildroot] [PATCH POC 5/5] qemu/x86_64: add midori samples for wayland and x11r7

[Arnout Vandecappelle <arnout@mind.be>]

On 03/28/16 14:41, Gustavo Zacarias wrote:
> On 27/03/16 08:55, Arnout Vandecappelle wrote:
>
[snip]
>>   Maybe it would be better then to first add a separate x86_64_defconfig
>> that creates a simple disk image for x86_64, and in a second patch add
>> the x86_64_midori_x11 and _wayland defconfigs. That would also make the
>> patches much easier to review.
>
> Yes, i already have a pc_bios_x86_64_defconfig, it just happens that this config
> can be used via qemu or real hardware.

  Well, if you post that defconfig, it should be possible to apply quickly, no? 
Nothing controversial there I expect.

> The idea is indeed to have a base "pc" config to have the kernel config fragment
> with all the drivers, though it might be a little overkill for qemu since many
> will go unused just adding up size.

  You mean that the pc_bios_x86_64_defconfig would use 
board/qemu/x86_64/linux-4.5.config + kconfig fragment to enable all kinds of 
network and display devices as modules, no?

>>   Oh, and you're also missing a readme.
>
> Oh yes.
>
>>   Maybe add a comment why this is needed.
>
> I'm using this for the volatile/permanent storage logic, will expand on this
> below...
>
>>   The meaning of this "Private" and "Permanent" is a bit vague.
>> Actually, what does the grow_root mean?
>
> s/Private/Volatile/
> Or "just run don't store anything".
>
>>   Why squashfs? Ext4 would be the more logical choice IMHO, you can make
>> it writable as well.
>
> The image is quite smaller than ext4, and also with ext4 and genimage you must
> know your target size or set it to some arbitrary number.
> Previously i used +128 MB free space for the image size on ext4, resulting on a
> squashfs4 wayland a target image of roughly 100 MB, whereas for ext4 it was more
> around 450 MB.

  OK.

> The extra free space is needed for the browser to store temporary files, the
> worst offender being watching some html5 video that potentially needs the full
> size on disk at one given time (it will go away once you close it).
> I decided that setting +128 MB wasn't nearly good enough - it would waste
> available space if the media is bigger (likely), or some people just don't want
> to store it altogether, or some $video wouldn't fit, so going to a "keep
> binaries RO and small" solution seemed better, with a boot option to select the
> mode. On volatile just throw a tmpfs for /root, if it's permanent (unimplemented
> yet, but not difficult) add an extra partition with an ext4 filesystem to store
> it. That's where rdev is needed, to find out the root filesystem device.
> That's also the reason e2fsprogs & parted are in there.

  Since it's not implemented yet, I'd propose to post something now already that 
just has the Volatile option (it can already be called that).


>
>>   Wouldn't it be better to enable everything that works on x86 as
>> modules? This is a bit a random selection...
>
> Yes, indeed.
>
>>   Same here.
>
> Ditto, it's not complete and we wouldn't want to complete with builtins.
>
>>   If / is rw, this isn't needed.
>
> Dual-strategy scenario above, without the permanent implemented yet.
>
>>   Can't wayland autodetect the backend like X?
>
> It has a default, but no, it doesn't autodetect.
> There are only two of interest here though: drm or fbdev, with fbdev being the
> most foolproof of all.
> We might throw this in a config file in /etc though.

  If / isn't writeable there isn't much point. You anyway have to adapt the 
config to change that defaults file, so in that case you can just as well change 
S99gui directly.

>
>>   Is it useful to have all these commented out lines?
>
> They were there for testing/debugging, they can go.
>
>>   post-build.sh would be a better name.
>
> Yes, sure.
>
>>   Couldn't it just be part of the overlay?
>
> Probably, i didn't clean-up everything, it wasn't intended to be a final config,
> just to get the ball rolling to discuss.

  We're discussing all right :-)

>
>>   Why mtools?
>
> Leftover from testing with syslinux, no longer necessary.
>
> A couple of extra comments from myself ("i'm not crazy!") ;-)
>
> * We can add squashfs support directly to the grub2 default, size growth is
> minimal and we're talking about x86/x86_64 which normally aren't that strained
> in resources. Hence drop it in the defconfig.

  OK for me, but not essential I think; it's not a problem that the grub config 
is non-default.


> * Fluxbox creates the menu config dynamically based on host installed/detected
> tools, it might be interesting changing this since you may miss a lot of
> entries, or have too many missing ones.
> Even having a simple base menu config and disabling the automatic one might be
> desirable, while adding a comment to fluxbox's Config.in

  This is completely independent of this defconfig, right? You are basically 
saying that the fluxbox.mk is wrong because it leaks host info into the target?

  Regards,
  Arnout

>
> Regards.
>


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF