[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: routing socket rou(n)ding?
On Feb 18, 2012, at 10:49 AM, Mouse wrote:
>>> (a) That appears to be dealing with PCI support, not routing socket
>>> support. It's the routing socket macro I'm curious about.
>> If you search for both macro names, you'll discover that this Milind
>> Choudhary made a sweep through the Linux kernel, including PCI
>> support, network drivers, and so forth. If the "not invented here"
>> syndrome or whatever other reason means that you don't want to
>> consider a change made in Linux, you'll even discover that it's used
>> in APR-- see APR_ALIGN in include/apr_general.h:
> No, it's not that I'm uninterested in things Linux did; if Linux has
> had to address this issue, I'm interested in what they did. But you
> gave no reason to think that the message you pointed at had anything to
> do with routing sockets. Also, the macros you cite still depend on the
> relevant sizeof() to return a power of two.
> As for "search[ing] for both macro names", I have no convenient way to
> do that; I do not have Linux source on hand.
>>> (c) Your citing this in response to my question implies that Linux
>>> runs on something with sizeof(long) not a power of two. Now I'm
>>> also curious what CPU (and/or machine) that is.
>> A DEC PDP-7 had an 18-bit word size, and the PDP-10 had a 36-bit word
>> size; I'm not sure you'll find anything much newer than that.
> What do those have to do with sizeof(long)? I didn't say, number of
> bits in a long not a power of two,, nor even size of a long etc; I said
> sizeof(long), because that's what was relevant - the macro uses (in all
> the variants I've personally seen) sizeof(long) as the basis for its
> You write that the NetBSD macro resembles
> #define RT_ROUNDUP2(a, n) ((a) > 0 ? (1 + (((a) - 1) | ((n) - 1))) :
> #define RT_ROUNDUP(a) RT_ROUNDUP2((a), sizeof(uint64_t))
> which is basically the same thing, except it uses uint64_t; presumably
> this refers to NetBSD newer than anything I have at hand (I haven't
> tracked NetBSD source at all since the GPLv3 was accepted). This is
> technically still at risk, since, even though all divisors of 64 are
> powers of two, uint64_t may include padding bits - for example, on a
> 22-bit machine, uint64_t could have 64 significant bits and 2 padding
> bits and thus (depending on the implementors' choice for char) have
> sizeof(uint64_t) equal something like 6. (Or not provide uint64_t at
> all, since 64 bits is not a native size; that at least would fail to
> compile rather than just silently producing weird rounding.)
Those macros where changed for NetBSD-6 so that the routing messages
are identical for 32-bit and 64-bit kernels. I think targeting NetBSD with
non-power-of-2 entities is a waste of time. If and when such a machine
comes along, we can adapt to it. But I don't think it's going to be any time
Main Index |
Thread Index |