On Thu, Sep 10, 2009 at 07:25:32PM +0200, Roland Mainz wrote: > Mahesh Siddheshwar wrote: > > If future enhancements are needed to extend xuio_t, a new xuio_type > > can be defined and extended that way. For extensions not specific > > to xuio, there also exists uio_extflg in the uio_t. Without a particular > > purpose an additional flag seems unnecessary for zero-copy right now. > > Right now... yes. But Unix has a little (IMO) ugly tradition of not > adding such flag fields and instead swamping the headers with many many > variations of one interface over time which could be avoided by use > having a flags field as argument (that's a generic issue).
Not just Unix. Any sufficiently old, and large piece of software tends to have such bloat (how many Windows APIs ending in "Ex" or "Ex2" are there?). It's a price we pay for backwards compatibility. A flags field is not enough -- you'd have to define the criticality of unknown flags, and what error code to return when unknown, critical flags are seen. Get it wrong and you end up paying for an unused flag field forever. Get it right and you still end up with the bloat of multiple interface definitions down the road. So what does a flags field buy you here? Nico --
