Hi Rainer, Rainer.scherg wrote: > there is another disadvantage, when having only one frontend > for combi devices. > You have to enhance the FE_GET_INFO and FE_GET_FRONTEND to > deliver tuning, modulation and capability information for several > modes/standards. no. They will only deliver all the info for the *currently selected* standard. As said - a frontend will change it's "personality" when a new standard is set. Different capabilities, different structure returned in FE_GET_FRONTEND/FE_SET_FRONTEND etc. > Using separate frontend devices will avoid this. > What might be needed is a kind of chaining information for frontends. > E.g. a list of frontends on the same card, when querying FE_GET_INFO. > So a FE_GET_INFO on ".../frontend0" has to return add. information like: > I'm am a super device, and i'm owner of... > .../frontend0, > .../frontend1, > .../frontend2 Yes, but that makes things complicated, in my eyes a LOT more than that single IOCTL. You get exactly the same lock problems as using a single device, so i belive my "FE_SET_FRONTEND-returns-EBUSY-when-frontend-is-opened" fixes this. > Advantage: older application do not break (but there might be errors > like EBUSY for a decive). They DO break. For example enigma2 assumes that all frontends on one adapter can be used at once, which is IMHO the correct behaviour. (or do you disagree here?) Having only one frontend would not break this. Of course the secondary standard couldn't be used, but that's better than NONE (because half of the time the one frontend works and the other don't, and the rest of the time it's vice versa. It's totally unpredictable, unless applications know this new enumeration stuff). The really only advantage is that simple applications like szap, which only open ONE frontend, can use a specific one. But I really don't like passing parameters in the frontend number... For these simple application, in my proposal, the frontend type has to be selected with a tiny userspace tool before. Think of -S2 again. Do you really want to have two logical frontends for each physical one? > Newer application have to check API version at runtime(!) if new > IOCTLs are supported by kernel (if not: fallback to old API or just > abort...). Here again my request for a simple FE_GET_API_VERSION... I'm not sure if this helps. Sure, having a FE_GET_API_VERSION is fine for displaying a fancy number, but does it really help? FE_SET_STANDARD (or any new IOCTL) will return an errorcode which indicates that it's not yet available. Then we have capability flags. Everything else can be kept totally backward compatible. We shouldn't waste compatibility just because there's a way to detect the version. With my proposal, an old driver would behave identically like a new one, which just doesn't support multiple standards. I think that's fine, and the expected behaviour. If you want to modify structure (sizes) depending on the API version, you either a.) have to use the *EXACT* api version in userspace as in kernel (we certainly don't want this!! Think of all this "wireless extension v13 doesn't match kernel version v15"), or b.) negotiate the used API version, and have kernel support for each API version (think of all that microsoft OLE/active-X stuff, where you need each interface up to 5 times to support different versions). We don't want this, either. > Rainer > Felix Domke schrieb: Du TOFUst :) Felix
