[rescue] Determining framebuffer driver major/minor device numbers?
derschjo at gmail.com
Tue Feb 9 00:38:31 CST 2016
Ok, scratch the below. Turns out I *was* missing something: Forgot to set
the permissions on /dev/cgRDI0 to read/write when I recreated it (d'oh). I
now have OpenWindows running in glorious 640x480 (albeit on a very nice
So apparently entries are required in both cdevsw *and* av_opstab. The
more you know...
On Mon, Feb 8, 2016 at 10:22 PM, Josh Dersch <derschjo at gmail.com> wrote:
> On Sun, Feb 7, 2016 at 7:06 AM, Andrew M Hoerter <amh at pobox.com> wrote:
>> On 2/7/16 1:39, Josh Dersch wrote:
>> I have rebuilt the kernel to include the cgRDI driver and the sbus board
>>> is recognized at boot (as cgRDI0). So far so good.
>>> Unfortunately, I have no idea what the device major/minor numbers are
>>> for this driver so I haven't yet been able to create the appropriate
>>> /dev/fb entry so that xnews is happy. Since I have no source or
>>> documentation for the driver, I'm at an impasse, unless there's a clever
>>> way to deduce this information.
>> I guess it goes without saying that /dev/MAKEDEV doesn't know about that
>> thing, but it might be worth checking first.
> Yep, not a Sun standard device and I don't have the official RDI media (if
> there ever was such a thing).
>> Assuming that doesn't work, it should be possible to figure out at least
>> the major number by looking at kernel tables. SunOS 4.x is old enough that
>> it still uses the traditional cdevsw method, and I believe that table
>> should be visible in a source file called 'conf.c' (or is it 'ioconf.c'?)
>> in the kernel tree somewhere. The array index of that driver in cdevsw
>> ought to be the major number.
>> It's possible that file could be autogenerated by config, if you haven't
>> already read through the manpage it does mention major/minor device numbers
>> so that information could be a good lead too:
>> (despite the domain that's not a FreeBSD manpage, heh)
>> The minor number is interpreted by the driver itself, so if you don't
>> have source or it's not listed in some file that came with the driver, that
>> will be a tougher problem. 0 is always a good guess to start with.
>> I haven't touched SunOS 4 in a very long time so the above is somewhat
>> speculative, but hopefully it will lead you in the right general direction.
> Thanks for jogging my memory. So, SunOS 4.1.3_U1 appears to be slightly
> more "advanced" than earlier BSDs in that it has a more modular driver
> model. Somewhat, anyway -- I haven't really dug deeply into the
> So, in /sys/sun4c/KERNEL_CONFIG/ioconf.c there's an array of dev_opslist
> structures (av_opstab), with one entry per driver; cgRDI (and others) are
> entered into this list. It looks like the dev_opslist struct defines the
> entrypoints normally entered into the cdevsw array in conf.c, but in a
> slightly easier to manage fashion, and in a way such that the array index
> does not define the device major number -- there are no empty entries in
> the array, just one entry per driver that gets loaded.
> In /sys/sun/conf.c there's the old-fashioned BSD-ish conf.c with the
> cdevsw array, and cgRDI did *not* have entries in the array (as other
> framebuffers and whatnot do). "Aha," says I, "I'll just add the requisite
> entries in an otherwise unused row and things'll just start working!." So
> I chose the row marked /* 36 */ and added the requisite entries for cgRDI.o
> (determined by dumping symbols from cgRDI.o). Recompile kernel, install,
> reboot. Create /dev/cgRDI0 with major 36, minor 0, link /dev/fb to it.
> Start openwindows and....
> Nothing. Can't open /dev/fb, no such device, etc. exactly as before.
> After some experimentation, it's kind of looking like the cdevsw array
> is ignored in favor of av_opstab. Tried removing cgRDI from av_opstab
> while leaving it in cdevsw to no avail.
> I assume having the entry in av_opstab sets everything up properly (the
> device does get enumerated at kernel startup) but the table provides no way
> to determine the device's major/minor numbers, apparently you have to know
> that ahead of time.
> Unless I'm missing something. Which is entirely possible...
> - Josh
>> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue
More information about the rescue