Hi guys, eMails which end up in different mailing lists get confusing. Anyway, about this issue:
On Fri, May 22, 2015 at 3:01 PM, Gary Thomas <[email protected]> wrote: > On 2015-05-22 06:49, Thomas PERROT wrote: >> >> Hi Gary, >> >> I know it is incorrect to define this variable in a no machine layer >> but that can be possible. >> >> For example, by using the meta-systemd layer, the recipe >> systemd-serialgetty define SERIAL_CONSOLE, so when the raspberrypi >> machine layer is applied, the SERIAL_CONSOLE isn't changed and the >> value is invalid. >> >> I know that it's incorrect for the meta-systemd layer to define this >> variable, so I have submit a another patch to fix it. >> >> But I think replace "?=" by "=" in raspberrypi machine layer is more >> robust. >> >> I also send this patch on the rpi mailing list. > > > IMO, the best solution would be to replace it totally since SERIAL_CONSOLE > is deprecated by SERIAL_CONSOLES. It should probably be: > SERIAL_CONSOLES ?= "115200;ttyAMA0" I definitely see the point of this patch even though, if someone overwrites this VARIABLE should be because that someone is you and wanted that for whatever reason (via local.conf for example). All the layers out there *should* not overwrite this variable. I didn't find the specific recipe you are pointing to in meta-systemd but in oe-core. By defining that variable there, the machine one won't get overwritten because it has precedence in parsing. So as long as systemd-seialgetty weakly assigns SERIAL_CONSOLES, it only provides a default value and won't overwrite machine definition. So, in my opinion, we should be safe in the current implementation. Now, as long as this variable is really carved in stone for RaspberryPi, maybe actually making it hard assigned would be a good idea and avoid any strange situations. As well, i'm voting for a patch which includes the upgrade to SERIAL_CONSOLES. Regards, -- Andrei Gherzan e: [email protected] w: www.gherzan.ro -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
