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

[Geert U. <ge...@li...>]

On Sat, 16 Jun 2001, Martin Erhardsen wrote:
> ----- Original Message -----
> From: "Geert Uytterhoeven" <ge...@li...>
> > 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

Ugh, unaligned 32 bit loads...

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

The main problem is that not all architectures support unaligned accesses. If
you want to use them, you must use the get_unaligned() functions. Currently
tdxfb doesn't do that.

Speedwise is not that bad these days anymore (supposed your CPU supports it),
since font data is in cached memory and the memory controller will load the
whole cacheline anyway, and the CPU runs at a much higher speed than the memory
bus. Even doing successive individual byte loads won't slow it down much if
your CPU is sufficiently faster than your memory bus.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds