[rescue] Determining framebuffer driver major/minor device numbers?

[Josh Dersch]

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:
>
> <
> https://www.freebsd.org/cgi/man.cgi?query=config&sektion=8&apropos=0&manpath=SunOS+4.1.3
> >
>
> (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
documentation.

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.

BUT

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...

Thanks,
- Josh




> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue