[i2c] [patch 2.6.23-rc5] i2c_msg kerneldoc

[David Brownell]

> >> > Ideally we'd have both TX and RX block paths able to take buffers of
> >> > any size physically possible with the encoding (1-255), and to report
> >> > just how many bytes were transferred.  Like most I/O interfaces ...
> >>
> >> What makes you think that 255 is the maximum size?
> >
> >The length is encoded in a single byte, hence 0-255 works at the
> >encoding level.  That's what!
>
> If and only if you encode the length in a single byte. Which is what
> SMBus block transactions do, but I2C doesn't have such a limitation. So
> is your suggestion only about SMBus-level transactions (i.e. about
> i2c_smbus_data, not i2c_msg)?

Only for code using those particular wire-level encoding conventions.
I2C is clearly on the "every bit is precious" end of the design spectrum,
so using two or four bytes for length would be uncommon.


> >In such cases it's usual to work from the encoding out, making
> >infrastructure work sanely with any values that can be encoded.
> >(Some developers surely will do so!  The PMBus folk are one example
> >here, but that's true with most wire protocol specs.)  Any policy
> >driven limitations should be left up to higher level code.
>
> This might be my lack of experience speaking, but I am not convinced.
> Given how explicit the 32-byte limit is in the SMBus specification, I
> perfectly understand why SMBus support was designed the way it was.

If you were only supporting SMBus, yes ... but that's the thing.
Distinguishing the marshaling scheme from that diminutive policy
limit imposed by SMBus was second nature.

There aren't many ways to represent "small" variable length blocks.
It was only a question of "when" that scheme would be used with
bigger blocks ... not "if". 


> >> > By the way, did you consider how this affects I2C_RDWR from userspace?
> >>
> >> No, and I do not really care. I2C_M_RECV_LEN is meant for SMBus block
> >> reads, and SMBus block reads should be done from userspace using
> >> I2C_SMBUS, not I2C_RDWR.
> >
> >In that case it's probably best to reject calls with I2C_M_RECV_LEN,
> >since otherwise getting the buffer length negotiations right will be
> >kind of error prone ... maybe even oopsable.
>
> Fine with me. Care to send a patch?

Sure, later this AM.

- Dave