Re: /dev/vme*

Quoting Bolo <[email protected]>:

>> > My guess is that they generate the alternate vmebus bus cycle codes
>> > needed to access vmebus devices with 16bit address/data regsiters.
>>
>> They just allow mapping a different range. That could be allowed for
>> /dev/mem directly as well. That's why I don't see the point in the
>> additional devices.
>
> My suns are off at the moment, and I don't have current source handy,
> but this may be applicable:
>
> 1) it would probably break SunOS executable compatability.   The
> =09execs can't open the vme address space to access the
> =09vme resources there properly.
>
> 2) IIRC (and it has been a long time) parts of the address space of
> the suns are setup to access the VME bus with different widths.  So,
> yes all it does is map a different range, but that lets the hardware
> do the accesses with the different widths.

The /dev/vme* devices do more than map different address ranges, they
also map those addresses with the right magic page type in the page table
entries, which is what really routes bus cycles to the VME bus (and in
the sun3 and sparc cases, at the right width).

The mmap magic cookies returned by the sun2 and sun3 mem.c:mmmmap()
include a PMAP_VME* value, which the pmap uses to build the page table
entries.  It looks like the /dev/vme* devices were never implemented
for NetBSD/sparc, although they did exist on SunOS/sparc.

Even though they aren't in MAKEDEV, and probably aren't used anymore,
it would be nice not to lose them..

--
Matt Fredette