Re: routing socket rou(n)ding?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>>  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.)

> However, my reason for citing the above is that many variants of
> ROUNDUP / ROUND_UP are buggy,

Including all the ones cited so far, on any architecture where the
relevant sizeof() is not a power of two.  (Well, possibly-buggy.  The
RT_ROUNDUP2() above does round up, even when n is not a power of two;
it just does so rather peculiarly and not very usefully.)  That's why I
was wondering whether any such system with anything like the BSD
routing socket existed, and, if so, what choice its designers had made
for dealing with the issue.

>>> and it appears to assume 2's compliment arithmetic....
>> Well, two's complement (not "compliment")
> True, and "routing socket rouding?" should be "routing socket rounding?"

Hoist by my own petard!  Well spotted.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B