From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751888AbeCVCbx (ORCPT ); Wed, 21 Mar 2018 22:31:53 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:3758 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751687AbeCVCbw (ORCPT ); Wed, 21 Mar 2018 22:31:52 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="38056902" Subject: Re: questions about header.S To: Thomas Gleixner CC: Ingo Molnar , "H. Peter Anvin" , , References: From: Cao jin Message-ID: Date: Thu, 22 Mar 2018 10:31:41 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.167.226.60] X-yoursite-MailScanner-ID: 365F64D0EFF3.A7A74 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: caoj.fnst@cn.fujitsu.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks very much for you hint! On 03/21/2018 05:57 PM, Thomas Gleixner wrote: > On Wed, 21 Mar 2018, Cao jin wrote: >> On 03/17/2018 06:01 PM, Cao jin wrote: >>>   I find two small questions which confuse me a little. >>> >>> 1. >>> # Check signature at end of setup >>> cmpl $0x5a5aaa55, setup_sig >>> jne setup_bad >>> >>> setup_sig is defined in setup.ld, which points to the constant also >>> defined in setup.ld, so I don't figure out in which case they don't >>> equal and jump to setup_bad? > > That's a lame sanity check to make sure that nothing overwrote the loader. > I see. >>> In my test, drop these 2 lines seems fine, system can boot without any >>> obvious error. > > Sure it does as long as you have no corruption. > >>> 2. >>> # Zero the bss >>> movw $__bss_start, %di >>> movw $_end+3, %cx >>> xorl %eax, %eax >>> subw %di, %cx >>> shrw $2, %cx >>> rep; stosl >>> >>> It is not a big deal, but I think replace "_end" with "__bss_end" make >>> more sense, and "_end" is already aligned to word length. And, there is >>> no other code use symbol "__bss_end". So I don't know is there any >>> reason to use "_end" here? > > It doesn't matter at all. But its also pointless to change it. > It does not matter and is pointless to change for kernel itself. It just may confuse a little for newbies who has interests. -- Sincerely, Cao jin