* Pali Rohár <pali.rohar@xxxxxxxxx> [150707 05:00]: > On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote: > > On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote: > > > Legacy bootloaders can pass additional information for kernel or legacy > > > userspace applications. When booting DT kernel then ATAGs structure is not > > > more visible after running kernel uncompress code. This patch stores full > > > ATAGs structure into DT "/chosen/linux,atags" entry, so kernel can later > > > reuse it and export via /proc/atags to userspace. > > > > I think you need to go through your commit messages and improve them, > > especially the ones with "TODO" in them. As long as there's still things > > to be done, they're obviously not ready for merging. > > > > I know, in cover letter email I wrote that documentation is not ready... > I send patches for review and comments (like yours). I think it is still > better to send something and mark it as incomplete. It could prevent to > work on something which will be again rewritten... > > > Moreover, exporting the ATAGS is questionable, even _if_ there are non- > > kexec programs making use of this. The ATAGs have _never_ been exported > > to userspace when kexec disabled is the kernel - it was introduced for > > kexec, and has always had this: > > > > config ATAGS_PROC > > bool "Export atags in procfs" > > depends on ATAGS && KEXEC > > default y > > > > Now, the fact that someone decided to start using it is pretty sad, > > because it means that if you disable KEXEC, userspace breaks. That's > > not a kernel regression in any shape or form, because /proc/atags has > > never been there without KEXEC enabled. That's a userspace bug, plain > > and simple. > > > > Given that, I'm in two minds about whether to accept the last two > > patches which make this more than just "for KEXEC use to enable a KEXEC > > kernel to be booted." > > > > Had it been provided without the KEXEC conditional, then I don't have > > a problem with these two patches. > > > > I understand it. Nokia originally invented their own entries in /proc/ > which export needed ATAGs from kernel in human-readable form, but all > those entries were non-standard and specific for Nokia's kernels. > > Do you have some other idea how to provide ATAGs information created > dynamically by legacy closed proprietary bootloader to userspace from DT > booted kernel? > > Anyway, for supporting kexec (with passing ATAGs) it is needed to have > working /proc/atags file, right? Yeah I think that since we already have it in /proc, we should just support it. And keep it behind CONFIG_KEXEC and CONFIG_ARM_APPENDED_DTB and hope we don't find other users for it.. Then reconsider the Kconfig dependencies if we do find other users. > > It also sets a precedent: by adding this into DT, it is creating a new > > DT ABI as well, and we'll end up seeing dts files with an ATAG block > > patched into them. > > > > Are the ATAGs at a fixed address on the N900? > > Yes, in board-rx51.c is: > > .atag_offset = 0x100 > > and Nokia Bootloader (proprietary) store them to that address. > > > Can that be handled in > > some kind of legacy file for the N900 which calls save_atags() on it, so > > we don't end up introducing yet more stuff that we have to maintain into > > the distant future? If not, what about copying a known working atag > > structure into a legacy file for the N900? > > I already asked question if it is possible to read ATAGs from DT booted > kernel. And somebody (do not remember who) wrote to ML, that it is not > possible and it can be done in that uncompress code. I guess the other option would be to keep the raw ATAG area reserved, and only initialize /proc/atags from a board specific initcall. But I think that would complicate the already fragile uncompress relocation code even further? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
