So, what do we want our interface to be, or our "contract", when we're wrapping commands in libcam?

Do we want to print to stdout/stderr by default, or provide a mechanism to get those strings back to the caller so that they can send them out via their logging interface or user interface?

I'm just thinking here about some library (really Ruby Gem) code I've written for Spectra that does some things that are similar to camcontrol, but the errors are handled in a way that is more friendly to the calling Ruby management application.

What number of 32-byte descriptors do you expect there be? If it is about heads, I'd guess about dozen. Wouldn't it be better to guess some size first to save one request in most cases?

Many tools were switched to calloc() to not call bzero explicitly.

chuck had the same feedback. I just did 4k since that's big enough to return lots of elements, and small enough to not matter.

Sure. That's not a bad idea.

I'm thinking of adding an error sbuf to cam_device that accumulates errors that the calling process can use to report errors and then cleanup...

So what about threaded processes with multiple threads accessing the same device? I guess we'll expect the caller to lock that as needed, just as they would have to if they were accessing any other fields in there.

That's probably a reasonable way to handle the static cam_errbuf issue with multiple threads/devices potentially putting error messages in it.

I think that's a sensible strategy.