Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs

[Martin E. <Mar...@ma...>]

----- Original Message -----
From: "Geert Uytterhoeven" <ge...@li...>
To: "Martin Erhardsen" <Mar...@ma...>
Cc: "James Simmons" <jsi...@tr...>; <lin...@li...>
Sent: Saturday, June 16, 2001 4:18 PM
Subject: Re: [Linux-fbdev-devel] Two bugs in fbcon_putcs


> On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > From: "Geert Uytterhoeven" <ge...@li...>
> > > On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> > > > I have a couple of further API questions.
> > > >
> > > > How about reading 3 bytes past the end of the bitmap.
> > > > I have noticed that 3dfx driver carefully avoids this,
> > > > but if this were allowed, it would avoid having a special case for
> > > > the last 3 bytes.
> > >
> > > Which bitmap?
> >
> > The bitmap used for drawing characters with putc and putcs.
>
> You mean the font data?

Yes

> > I was wondering if reading 3 extra bytes past the end could
> > cause a segmantation fault.
>
> In theory yes. But why would you want to read more fontdata than is present?

The 3dfx driver uses unalligned 32 bit loads to read the font data, and
has a special case for the last bytes to avoid reading past the character data.
If reading a few extra bytes were allowed, then this could be avoided by
just reading the extra data, because the accel engine doesn't use the extra
bytes in the last u32.

Are unalligned loads a bad thing in kernel drivers? I could modify the
driver, so that it only loads u32s from alligned adresses, but this would
either make character sizes where the number of bytes in a character
is 3 modulo 4 (i.e. 7,11,15,..) slight slower, because it would require
writing a extra u32 to the accel engine in half of the possible allignments,
or this this extra write could be avoided by shifting the data before writing
it to the accel engine.