[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK4o1WyJwo85SS=EaFitAzAuR3WOfOKNWkdUpDaXnRQ74hA+Rg@mail.gmail.com>
Date: Fri, 17 May 2013 08:28:59 +0100
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
On Fri, May 17, 2013 at 2:56 AM, Rich Felker <dalias@...ifal.cx> 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 <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?
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
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.
