Received: by 10.192.165.156 with SMTP id m28csp523519imm; Wed, 11 Apr 2018 03:08:25 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+tdveOSW8NvUToYYwJM0sDwGSF6TgTpxUk0buHprs58kDtdOZdRK3ijICUtqG2dE/Y7ire X-Received: by 10.101.65.195 with SMTP id b3mr2971193pgq.118.1523441305113; Wed, 11 Apr 2018 03:08:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523441305; cv=none; d=google.com; s=arc-20160816; b=R6+bUiiYpdaBm5bFkhwPNmAK5b/a4rdw3CKzCpsNjCUSPdBt7IoOBQWihsTJhq1zWH v5s6IFP+1KSXTI45a55x8Oq9BrbXLMhKpDH245EluaHrmS0gRUPJW4xCGlCVOwLxLMKS wQhZm9A/uMBe8kmzhF6ZNAI3BzBa8oTYlJsj5CfPbrdteO5Myp61PVEp4I8I28o0Ouv8 Do+3fPRDKWwk/FiAcSo0KHL7XECd7EHubDmtCVXqJBmqd/vCyf/Tx915tOx/1bg3UYwk MSlxFiUj8z7bja1w6enG0S1BzgCFAMQ0Yqh/sio8sVaqnM+Q2qxQb4DkoH5p9Y4JskOs x43A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=s0ZzmoJjDJ9pbpLzjgg/sNSzivHU6fHJfQjlPuhoGxo=; b=AWIDFD9E1BMkdaTbo2cT5ware1Xb7vHHyNRH92AgJ3jK5e4OJP+OdPZTqhkMqIk8lw Ryf1lSPYvzUag4rBZS28p/qw9UpfALHoxZiOZGk2JyQCaQXTYY+9v5qVFIRkw2/8hF+U BzDcG27dpWs4qeFecQkI76TAcVaW8ZGdqbqljkWx5iB5l3bGjB9M2Pg0B/nw3xe9ShoP t0yamojJR3/GDnVhn09B5x6DCovZC6HvUO+ZCd4fV8bhizPQ3XcRZJiV0A9+yIJWcamE /hz/G7DrZafNs/g4l5gG9p1jZ0Ue2H2BLOa6UzmelZG+jpBiukQM6WEkfjHYF2J2cnqs bt3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a33-v6si793520pld.125.2018.04.11.03.07.47; Wed, 11 Apr 2018 03:08:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752016AbeDKKE0 (ORCPT + 99 others); Wed, 11 Apr 2018 06:04:26 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:51660 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751546AbeDKKEZ (ORCPT ); Wed, 11 Apr 2018 06:04:25 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 9CBD2DE1; Wed, 11 Apr 2018 10:04:24 +0000 (UTC) Date: Wed, 11 Apr 2018 12:04:15 +0200 From: "gregkh@linuxfoundation.org" To: "Zhang, Ning A" Cc: "pombredanne@nexb.com" , "tglx@linutronix.de" , "kstewart@linuxfoundation.org" , "linux-kernel@vger.kernel.org" Subject: Re: 3 version of MKDEV: kernel, uapi, libc, why? Message-ID: <20180411100415.GA26356@kroah.com> References: <1523436662.1414.12.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1523436662.1414.12.camel@intel.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 11, 2018 at 08:51:03AM +0000, Zhang, Ning A wrote: > Hi, Greg, Thomas > > I find 3 version of MKDEV (actually 2 + makedev) > > in include/linux/kdev_t.h > > #define MINORBITS 20 > #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) > > in inlcude/uapi/linux/kdev_t.h > > #define MKDEV(ma,mi) ((ma)<<8 | (mi)) Isn't history grand :) Those are different because we increased the size way back in the 2.5 kernel (I think), so we had to do so in a way that did not break userspace. > in Android bionic > > #define makedev(__major, __minor) \ > ? ( \ > ????(((__major) & 0xfffff000ULL) << 32) | (((__major) & 0xfffULL) << > 8) | \ > ????(((__minor) & 0xffffff00ULL) << 12) | (((__minor) & 0xffULL)) \ > ? ) Fun stuff :) > if I use mknod("renderD128", S_IFCHR|0666, MKDEV(226, 128)); > I get wrong device: > crw-rw-rw- 1 root graphics?0, 57984 2011-11-11 11:20 renderD128 > > > if I use ("renderD128",S_IFCHR|0666, makedev(226, 128)); > I get right device. > > but, when I use: mknod("card0", S_IFCHR|0666, MKDEV(226, 0)); > I can get right device. Why are you calling 'mknod' at all? The kernel does this automagically for you already, in devtmpfs. You should not have to do this on your own ever. Unless you are using a crazy Android system that doesn't use that filesystem. And if you are, go complain to those developers about it, not much we can do from within the kernel. And the answer is yes, use the right macro, for when you want to really do this. Your libc should provide the correct one, trust it. good luck! greg k-h