On Mon, Sep 15, 2014 at 11:34:19PM +0200, Uwe Hermann wrote: > > If the sp_drain() is indeed required, please add them in the ols driver > directly. We're planning the reduce the amount of serial wrappers in > serial.c over time (in favor of direct libserialport calls), we'd rather > not add new wrappers like serial_drain() at this point.
I disagree. That may seem odd, since I started libserialport, and one of the ideas for that project was to eliminate the need for libsigrok to have its own internal serial calls at all. But now that all the libsigrok serial functions have been stripped down, to the point where all the actual work is done in libserialport, it's clear to me that there is in fact a real need for most of the remaining wrappers. The new serial_drain function in this patch illustrates this perfectly. Although the actual function is encapsulated in the library call, there is a bunch more stuff that is specific to libsigrok: - We need to validate, and then extract a port handle from, our own data structure. And we do still need our own, because we have to store state and data about our usage of the port, not just the port handle. - We need to log what we're doing for debugging, and log error messages when things fail, all through the libsigrok logging mechanism. - We need to translate libserialport return codes into libsigrok ones. None of this is very interesting, but if we don't put this stuff in a wrapper we will just duplicate it at every call site, badly. We can get rid of some remant bits of the wrappers that simply translate between old internal API, and new libserialport API. Things like the flags passed to serial_open, and most of serial_set_params. That work has been left out thus far to avoid touching driver code, but we should finish the job. Drivers can express their configuration requirements in terms that can be passed straight through to libserialport calls. The only wrappers that really need removed in my view are serial_read() and serial_write(). These are already just stubs, that need to be replaced everywhere with explicit calls to either the blocking or nonblocking variants. Martin ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
