Re: routing socket rou(n)ding?

[Matt Thomas <matt%3am-software.com@localhost>]

On Feb 18, 2012, at 10:49 AM, Mouse wrote:

>>>> http://lkml.org/lkml/2007/4/1/50
>>> (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
> operations.
> 
> You write that the NetBSD macro resembles
> 
> #define RT_ROUNDUP2(a, n)       ((a) > 0 ? (1 + (((a) - 1) | ((n) - 1))) : 
> (n))
> #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 
soon