Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Eric Sultan wrote:
>>> 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?
>>
>> Yes, I think you are.
>>
>> What I'm talking about is an upgrade of Solaris 10 (or earlier!) to
>> Solaris Nevada (or later). To be quite honest, I doubt many people
>> care whether Xsun or Xorg is running on their system, provided that
>> they have *X11* for their *hardware*.
>
> There is no such upgrade path at the moment (S10 or SX:CE to
> OpenSolaris IPS based system) so lets not assume that *if* one is
> developed it can't be taught to deal with this problem of switching
> from Xsun (and its associated kernel drivers) to Xorg. At this time
> we don't even know if the hardware that the new rfb driver will be
> supported on these future releases because we don't know when they are.
I'm unhappy with designs which exclusively rely on OpenSolaris being
non-upgradeable, particularly if the product in question is intended for
SX:CE (and ultimately possibly some future Solaris 11 product). Right
now the relationship between SX:CE (and indeed Solaris itself) and
OpenSolaris releases is not adequately defined, I think, to say that no
upgrade path will ever be desired by some significant percentage of Sun
customers.
(Put another way--- IPS not being upgradeable isn't a problem, since its
not a Solaris Express technology -- yet, but I think this case is
different because the new driver is equally applicable to both Solaris
Express and OpenSolaris. And more to the point, the EOF of Xsun is
relevant to Solaris Express.
>
> If you are running S10 or SPARC today or SX:CE on SPARC and upgrade to
> an SX:CE release then the default is still Xsun and the older pfb/nfb
> drivers will still be in your driver_aliases. If someone wishes to
> manually switch to Xorg/rfb on SX:CE then that is a concious choice
> and will require manual intervention - documentation of how to do that
> would be an excellent thing for this case to provide.
However, at some time soon, I believe, the Xsun drivers will go away,
and all that will remain will be this new driver. Its worth some effort
to try to make the upgrade smooth as possible.
>
> If you install the yet to be released OpenSolaris on SPARC the you
> won't have Xsun and never will have had it or pfb/nfb you only have
> Xorg and
> this rfb delivered by this case.
>
> You are really solving a problem that doesn't exist, lets not give the
> project team more work to do.
I don't think the problem doesn't exist, or I wouldn't have mentioned
it. I'm not worried about just OpenSolaris, but Solaris Express.
>
>> That's why I'm proposing that you treat rfb as a drop in. It doesn't
>> have to drop in to Xsun, but it should drop in from a user-experience
>> perspective. (Modulo some known differences, such as lack of
>> Display PostScript.)
>
> I think in this case it is a bad idea. This isn't like the problems
> seen in networking drivers. By requiring rfb to be a dropin
> replacement for pfb/nfb you means more work for the project team to
> solve a problem that I really don't think exists. I believe we will
> have better architecture by not forcing rfb to be a drop in
> replacement for the old Xsun based architecture.
/etc/driver_aliases conflicts are a major PITA. There are hackish
workarounds, but its far better, IMO, to avoid the conflict in the first
place, if possible.
There is also some user accessible knobs (/dev/fb/ links, for example),
where its better, IMO, if we don't change the knobs.
>
> For comparison the equivalent thing was not required of x86 when it
> made the switch from Xsun to Xorg.
>
That's an interesting datapoint. I'm not sure how good the comparison
is though, given the very different architecture of how framebuffer
drivers work on x86 versus SPARC. (IIUC, most of the Xsun drivers did
not have kernel drivers with them, apart from some kind of generic
VGA/VESA mapping driver, whereas the SPARC framebuffer drivers do far
more including full rendering of the text console. But maybe someone
else will correct me if I've misunderstood.)
In any case, all of my comments in this case are at most TCA class
advisories/requests, and I don't think the work is terribly
complicated. If analysis shows otherwise, or there are other reasons
not to take the effort, then I wouldn't object to just delivering rfb.
(But I *suspect* that the work required is an hour or two at most, not
weeks or even days of effort.) If we can save a few tens of hours
dealing with service calls by an upfront hour in engineering, I
generally think its a good tradeoff.
But then, my view has always been that it is appropriate for ARC members
to request or recommend that project teams do more work if it can
improve the project. Project teams working with business teams
ultimately make the decision about whether the work is justified or not.
Anyway, in this case, I already spent about 30 mins on the phone with
Eric Sultan talking about my concerns, and how to address them, and
offered some specific example code to look at. Eric graciously agreed
to think about it, and get back to me. And ultimately, if he tells me
the project team has decided not to pursue my suggestions for one reason
or another, then I'll be fine with it. (And I'll be confident that at
least the decision that was made was done from an informed point of
view, which is really all any of us can ask.)
-- Garrett
