[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130517015629.GY20323@brightrain.aerifal.cx>
Date: Thu, 16 May 2013 21:56:29 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On Thu, May 16, 2013 at 05:12:04PM +0100, Justin Cormack wrote:
> On Wed, May 15, 2013 at 9:17 PM, Rich Felker <dalias@...ifal.cx> 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?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
