I'm not sure I properly understand the dimensions of the problem. Wherever Xsun has been EOL'd and removed, there should not be any compatibility issues. When Xsun is removed, so must Xsun-only components such as nfb and pfb. Issues of coexistence could occur in systems that support both Xsun and Xorg, and so might want both nfb/pfb or rfb. If this is an issue, the driver binding can be unambiguously specified in the /etc/driver_aliases file.
Using the rfb code as a drop-in replacement for the nfb/pfb code doesn't solve the problem. When one *wants* to run Xsun on a system that has both Xsun and Xorg support, one would need the old nfb or pfb drivers instead of the Xorg-compliant rfb driver. Renaming rfb as nfb and pfb wouldn't get the job done, would it? Am I missing something here? -- Eric Garrett D'Amore wrote: > Eric Sultan wrote: >> The intended delivery target for rfb is OpenSolaris. The OpenSolaris >> system will not support Xsun, and hence will not have the >> Xsun-compatible pfb and nfb software components. There should not be >> a conflict, then, between pfb/nfb and rfb. >> >> Alan asked about whether the pfb/nfb kernel device drivers could be >> modified to work with the Xorg ddx module. In theory, they could, >> but it would produce a rather chimerical product. The rfb product, >> for example, uses the DRI/DRM, and the pfb/nfb products do not. >> >> Since Xsun has been EOL'd and we're working towards an Xorg >> environment, the project chose to move forwards with an >> opensource-derived Xorg-compliant support for the XVRs 50, 100, and 300. >> >> Edward asked if rfb would support the Coherent Console system. Yes, >> that is the plan (and should be, since it's the SPARC graphics team >> that originally requested Coherent Console support). > > The only objection I have here is that the EOL of Xsun is not *just* > for OpenSolaris, but also for whatever Solaris release (11.x?) might > follow S10. I would really encourage the project team to consider a > solution where the driver names don't change, so that an upgrade from > S10 (or earlier) to this driver could be done "painlessly". > > Having different device driver names for S10 and OpenSolaris is only > likely to increase pain elsewhere in the future. (And yes, this is a > Sun-only concern, not really related to OpenSolaris, but it is worth > resolving nonetheless.) > > Its also possible that at some time in the future, "upgrades" between > Solaris (Sun) and OpenSolaris might be desired. While there are > numerous technical hurdles to solve for such, I would prefer to avoid > putting in *new* hurdles if I could help it. > > -- Garrett >> >> -- Eric >> >> >> >> Garrett D'Amore wrote: >>> Alan Coopersmith wrote: >>>> Eric Sultan wrote: >>>> >>>>> I'd need to consult with someone that knows release engineering >>>>> better >>>>> than I, but I'd think that the rfb driver should be made mutually >>>>> exclusive of the nfb and pfb drivers. I'm not familiar enough with >>>>> packaging and installation issues to know how to achieve this. >>>>> >>>> >>>> I don't think there is a way to do this other than choose one to not >>>> include with Solaris. >>>> >>> >>> Yes. And it creates nightmares on upgrade. If at all possible, I >>> *highly* recommend renaming the driver to the legacy names, so it >>> appears as a "drop in" replacement. >>> >>>> >>>>> Both drivers can exist in the system without competing with each >>>>> other. The first one found in the /etc/driver_aliases file is the >>>>> one that >>>>> would be used, but this doesn't seem to provide a useful mechanism >>>>> for >>>>> binding the driver to the device. >>>>> >>>> >>>> So how would users choose which to run? Why does a different >>>> kernel driver >>>> even need to be provided - can't the Xorg ddx module work with the >>>> old ones? >>>> >>> >>> Good point -- I look forward to Eric's reply. >>> >>> As an aside, I'm disappointed about the open source, but hopefully >>> we'll at least get binary redistribution rights? I'm also not sure >>> what the etiquette of submitting an open ARC case for a closed >>> source bit of software is. >>> >>> -- Garrett >>> >> >
