From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id B24333858D3C for ; Wed, 18 May 2022 03:40:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B24333858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [10.20.4.187] (unknown [10.20.4.187]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9AxGtiuaoRiTaIaAA--.29753S3; Wed, 18 May 2022 11:40:30 +0800 (CST) From: caiyinyu Subject: Re: [PATCH v4 09/13] LoongArch: Linux ABI To: Adhemerval Zanella Cc: GNU C Library , xuchenghua@loongson.cn, joseph_myers@mentor.com, Arnd Bergmann References: <20220509022611.1248063-1-caiyinyu@loongson.cn> <20220509022611.1248063-10-caiyinyu@loongson.cn> Message-ID: Date: Wed, 18 May 2022 11:40:30 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID: AQAAf9AxGtiuaoRiTaIaAA--.29753S3 X-Coremail-Antispam: 1UD129KBjvJXoWxCFW8Jry5tFyxArW5Xw17GFg_yoW5XF4fpF s8X34kCrs3Ja4I9r1Yqas8Wryakw1rKw47CF1rKayUJFy5Xrn2gr9rWF4j9r4DXws3ZrWv vr4qk34rury7trJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvv14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26F4j 6r4UJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26F 4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv 7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r 1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwCYjI0SjxkI62AI1cAE 67vIY487MxkIecxEwVCm-wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8Jw C20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAF wI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjx v20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2 z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73Uj IFyTuYvjfU5WlkUUUUU X-CM-SenderInfo: 5fdl5xhq1xqz5rrqw2lrqou0/ X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2022 03:40:40 -0000 在 2022/5/11 下午3:08, Arnd Bergmann 写道: > On Mon, May 9, 2022 at 4:26 AM caiyinyu wrote: >> + >> +#include >> + >> +/* In 64-bit ISA files are always with 64bit off_t and F_*LK64 are >> the same as >> + non-64-bit versions. It will need to be revised for 128-bit. */ >> +#if __WORDSIZE == 64 >> +#define __O_LARGEFILE 0 >> + >> +#define F_GETLK64 5 /* Get record locking info. */ >> +#define F_SETLK64 6 /* Set record locking info (non-blocking). */ >> +#define F_SETLKW64 7 /* Set record locking info (blocking). */ >> +#endif >> + >> +struct flock >> +{ >> + short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */ >> + short int l_whence; /* Where `l_start' is relative to (like >> `lseek'). */ >> +#ifndef __USE_FILE_OFFSET64 >> + __off_t l_start; /* Offset where the lock begins. */ >> + __off_t l_len; /* Size of the locked area; zero means until EOF. */ >> +#else >> + __off64_t l_start; /* Offset where the lock begins. */ >> + __off64_t l_len; /* Size of the locked area; zero means until EOF. */ >> +#endif >> + __pid_t l_pid; /* Process holding the lock. */ >> +}; >> + >> +#ifdef __USE_LARGEFILE64 >> +struct flock64 >> +{ >> + short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */ >> + short int l_whence; /* Where `l_start' is relative to (like >> `lseek'). */ >> + __off64_t l_start; /* Offset where the lock begins. */ >> + __off64_t l_len; /* Size of the locked area; zero means until EOF. */ >> + __pid_t l_pid; /* Process holding the lock. */ >> +}; >> +#endif > Not sure why these are provided here, the kernel has no loongarch64 > specific > interface for flock in the current version, so either this refers to > an older version > of the kernel port, or it is something that could be generalized into an > architecture-independent file in glibc. > > Arnd There are struct flock and flock64 we need in glibc bits/fcntl.h, but the macro F_GETLK64 F_SETLK64 F_SETLKW64 in sysdeps/unix/sysv/linux/bits/fcntl-linux.h are: ... # define F_GETLK64      12      /* Get record locking info.  */ # define F_SETLK64      13      /* Set record locking info (non-blocking).  */ # define F_SETLKW64     14      /* Set record locking info (blocking).  */ ... what we need: +#define F_GETLK64 5  /* Get record locking info.  */ +#define F_SETLK64 6  /* Set record locking info (non-blocking). */ +#define F_SETLKW64 7 /* Set record locking info (blocking).  */ x86 ia64 s390 and aarch64 have the same problem and they all use their own fcntl.h. Define new value of these macro in sysdeps/unix/sysv/linux/bits/fcntl-linux.h or add fcntl-linux.h in loongarch port or keep the status quo?? any ideas?? Thanks.