On Sun, 28 May 2000, Matthias Drochner wrote:

> mrg@eterna.com.au said:
> > argh. this mmap/int thing needs to die. 
>
> Agreed. But this would mean a change of the driver interface.
> There were some ideas for further enhancements (at least
> I had some idea to make the initial range check a single
> call) which could be integrated to avoid the interface to be
> modified more often than necessary. After the release...

It would be really nice to solve this once and for all, especially the
return value from (*dev->mmap)() so we don't need to come up with some
silly wrapper to somwhow try to sqeeze 64-bits of addressing information
into a 32-bit `int'.  I didn't do this when I added vaddr_t and paddr_t to
prevent huge breakage, especially with LKMs.  Now we're switching to ELF
on most ports we might as well break LKMs as well.

> Wouldn't it be better to make the voff_t unsigned btw?

Sigh.  vaddr_t is supposed to hold a pointer in a machine's virtual
address space.  voff_t is supposed to hold an offset in the machine's
virtual address space, the equivalent of the new C9x ptrdiff_t.  I
expect they should be of the same length, if not the same size.  Otherwise
when you add a voff_t to a vaddr_t to get another vaddr_t strange things
happen.  And if I have a negative offset I suppose it should be treated as
a negative number.  So, no, I don't think you want to make voff_t usigned.


Eduardo Horvath