From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3325 Path: news.gmane.org!not-for-mail From: Justin Cormack Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Fri, 17 May 2013 08:28:59 +0100 Message-ID: References: <20130509144528.GK20323@brightrain.aerifal.cx> <1368398543.43199.YahooMailClassic@web160405.mail.bf1.yahoo.com> <20130515201700.GV20323@brightrain.aerifal.cx> <20130517015629.GY20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1368775753 29624 80.91.229.3 (17 May 2013 07:29:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 May 2013 07:29:13 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3329-gllmg-musl=m.gmane.org@lists.openwall.com Fri May 17 09:29:15 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UdF6H-00080h-Lm for gllmg-musl@plane.gmane.org; Fri, 17 May 2013 09:29:13 +0200 Original-Received: (qmail 12125 invoked by uid 550); 17 May 2013 07:29:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 12114 invoked from network); 17 May 2013 07:29:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=specialbusservice.com; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=K7UIBFa7dHy+MdT7K7sF3ZQbEhN5g5RARPjugt7dnfU=; b=ShS1Ogwibm4wOxSIRPW1mWf5/3RQ5lvJ4a9JRG5U94lMSFml3WtcfFkzoiq5MP2ZgW bHCb6TvLd4DQcNpEWl1RLFnPl88u/7VTugiOKr3L7ZOn8Kgg+AF7LEkQo26yKIhl/DoK Gue79yYatfTFXplMncMq7vmij60OOosKtZTcc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=K7UIBFa7dHy+MdT7K7sF3ZQbEhN5g5RARPjugt7dnfU=; b=junaZgJpc1tLFaiVrLqarE7g2XdaZuG6OFotPuUgARMNsa+eOCr1rfamlf4QUw1KZZ iDUJBrEx+dkh2+VrQWZhNSJg1Uc25Awd+G5guZfhMEIWXeG9tDXbv9N5vw0uYsMEaNGF UNrYDP/WSP6Bi6rNeyzEASsV/8tJBnwW2w+VXwaKwTaBJpYAa9T2TaZGbRTJ8zitbp+6 2P5nEsli4n0KZuqbvssou7NxFTpVOhIgcadzx//roH3ySkVN5ToOt9aw/nfOC88VxJjn SIfxnT7r1Yhxm5xnXOriXaYZOtWVKDM+uCUKgtBqCTmIfNVEJ5lcyEdeHl71a6KiYQXg odRg== X-Received: by 10.66.233.97 with SMTP id tv1mr47570586pac.96.1368775740133; Fri, 17 May 2013 00:29:00 -0700 (PDT) In-Reply-To: <20130517015629.GY20323@brightrain.aerifal.cx> X-Gm-Message-State: ALoCoQk4KQ8YfOCZaMOAHyLPaVa0XPSFvWuKq7tjxTPFkbU6M5T1nW6v2oDZg5vO5kHZJYifZwZa Xref: news.gmane.org gmane.linux.lib.musl.general:3325 Archived-At: On Fri, May 17, 2013 at 2:56 AM, Rich Felker wrote: > On Thu, May 16, 2013 at 05:12:04PM +0100, Justin Cormack wrote: >> On Wed, May 15, 2013 at 9:17 PM, Rich Felker wrote: >> > On Sun, May 12, 2013 at 03:42:23PM -0700, Brad Conroy wrote: >> >> In case I don't get around to fully researching it, the kernel spews >> >> out major and minor numbers in /sys that are greater than 255, so >> >> the makedev in /sys/sysmacros.h is insufficient (also major() and >> >> minor()???) I noticed because I wrote a shell script that populates >> >> /dev from /sys in <0.2 seconds but failed for large major/minor >> >> numbers when I built busybox with musl. At first glance, it looks >> >> like dev_t needs to be uint and have the extra bits from major and >> >> minor prepended as in the kernel's dev_t? >> > >> > Should be fixed in git. Let me know if it doesn't work right. >> >> mknod/mknodat still does return syscall(SYS_mknod, path, mode, dev & >> 0xffff); - I believe it should pass the full 32 bits. >> >> Also the top 32 bits are only for compatibility with glibc I think, >> not sure the macros should touch or use them, as the kernel has 32 bit >> dev_t and no plans to change. > > mknod and mknodat should be fixed now. Anything else? I don't see much > harm in having the macros match what glibc does, and it could be > useful if the kernel allows 64bit device numbers on 64-bit archs. But > if not, there's also an argument to be made for reducing code size by > dropping the part of the macros for the high bits. What do you think? Given that the struct stat64 the kernel uses specifically defines st_rdev as unsigned long long, it probably makes sense to leave dev_t as 64 bits. I would be inclined to not do anything with the extra bits in the macros though, as the meaning of those bits is undefined, and might not be defined as glibc does (seems to be based on what NetBSD does), and changing the macros does not break anything. Justin