I've considered Garrett's concerns and had a small out-of-band discussion with him to be sure I understood his perspective. I concede his point, and discussed it with the project team and tried to find a way to accommodate the concern about renaming support for an existing device.
I'd considered using a thin layer in the kernel to allow the user to continue to use the nfb and pfb names, while plumbing to the rfb modules. This could allow the user to not be concerned about whether he's running pfb/nfb or rfb but in the event that a system, not currently planned, has both Xsun and Xorg it would need pfb/nfb to be plumbed to the pfb/nfb modules for Xsun and to the rfb modules for Xorg. We've not found a way to do this gracefully. We think it unlikely that a user, other than a developer prepping for the Xsun/Xorg transition, would want to have both Xsun and Xorg on his system. It seems cleanest to transition the user-visible name to rfb when the system is configured to run Xorg. Recognizing that we have been teaching our users that pfb is the driver for the XVR-50 and XVR-100, and that nfb is the driver for the XVR-300, we think it makes sense to help the transition for those users that need to know the device/driver binding. A conventional way for users to tell what SPARC graphics devices they have is to use the command "fbconfig -list". That command produces a two-column list, each row of which gives the /dev/fbs entry for a device and the name of that device's configuration utility. We'll modify the -list output to include a third column for the device type, e.g. showing that /dev/fbs/rfb0 binds to XVR-300, that /dev/fbs/kfb0 binds to XVR-2500, and so forth. -- Eric Garrett D'Amore wrote: > 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 >
