[PATCH] report that OAM is not supported

[Duncan Sands]

> > On the other hand, won't the code be more efficient if
> > they are both just "unsigned"?
> 
> Why would it be?  We dont enforce any alignment, so the compiler is free
> to choose the most efficient one.

Because logical operations (such as shift) may not be same for an 8 bit
unsigned quantity as for a 32 bit unsigned quantity (think of a left
shift).  So the compiler will not be producing the same opcodes.  Aren't
operations on int sized things (i.e. register sized) usually the
fastest?  (I'm not saying that the ops on other sizes are slower, just
that they're not faster).  Anyway, it's not like we care.  The slowest
thing in this part of the code is probably accessing the individual
bytes in "source".

> > Finally, the ATM code uses
> > short for vpi and int for vci (and so do we in
> > struct usbatm_vcc_data and usbatm_find_vcc), so why not just
> > use those here?
> 
> Well, I was somewhat uncomfortable with bit shift operators and signed
> types.  They may be OK, though: I'll try to check with a C handbook.

I don't think there's a problem, because the values we are dealing with
are small compared to the variable, so we never get anywhere near the
sign bit.  I remember thinking about this when I first wrote the code,
and doing some testing.  It was fine.

> Anyway that was more about putting var and cached_var declarations on
> the same line, to emphasize their relationship and make certain that
> both are of the same type.

Yes, I liked that bit.

Ciao,

D.