mbox series

[0/5] Preparation work for using font_desc in vc_data

Message ID cover.1603788511.git.yepeilin.cs@gmail.com
Headers show
Series Preparation work for using font_desc in vc_data | expand

Message

Peilin Ye Oct. 27, 2020, 4:27 p.m. UTC
Hi Daniel, Hi Greg, Hi all,

We are planning to use `font_desc` instead of `console_font` in `vc_data`,
and this is just some prep work for it. It doesn't do much, but at least
it removes two "FIXME"s in fbcon.c :)

Peilin Ye (5):
[1/5] fbdev/atafb: Remove unused extern variables

  Searching for `fontdata` gave me this in fbdev/atafb.c:

  extern unsigned char fontdata_8x8[];
  extern unsigned char fontdata_8x16[];

  ...which freaked me out, since in 6735b4632def ("Fonts: Support
  FONT_EXTRA_WORDS macros for built-in fonts") I changed them from char
  arrays to structures, in lib/fonts/. Fortunately it turns out these
  extern variables have nothing to do with lib/fonts/, and are not being
  used anywhere, so remove them for less confusion.

  m68k cross-compiled.

[2/5] Fonts: Make font size unsigned in font_desc

  Our goal is to use `font_desc` "everywhere" in the kernel, and signed
  `width` and `height` is inappropriate.

  Also, change some printk() format identifiers in console/sticore.c from
  `%d` to `%u`. parisc cross-compiled.

[3/5] Fonts: Add charcount field to font_desc

  Add `unsigned int charcount` to `font_desc`, and update each of our 13
  built-in fonts.

[4/5] fbcon: Avoid hard-coding built-in font charcount
[5/5] parisc/sticore: Avoid hard-coding built-in font charcount

  Everyone (tty, fbcon, sticore, etc.) is assuming that all built-in fonts
  have 256 characters, and is using hard-coded 256 or 255 everywhere.
  These two patches removes some of them. [5/5] is parisc cross-compiled.

  Now is a good time to review all find_font() and get_default_font()
  callers:

  drivers/media/pci/solo6x10/solo6x10-enc.c      133 const struct font_desc *vga = find_font("VGA8x16");
  drivers/media/test-drivers/vimc/vimc-core.c    268 const struct font_desc *font = find_font("VGA8x16");
  drivers/media/test-drivers/vivid/vivid-core.c 1928 const struct font_desc *font = find_font("VGA8x16");
  drivers/usb/misc/sisusbvga/sisusb.c           2285 myfont = find_font("VGA8x16");
    * These 4 only care about font VGA8x16, so let them be for now;

  drivers/video/console/sticore.c                499 fbfont = find_font(fbfont_name);
  drivers/video/console/sticore.c                501 fbfont = get_default_font(1024,768, ~(u32)0, ~(u32)0);
    * Uses 255 and 256, (hopefully) cleaned up by [5/5];

  drivers/video/fbdev/core/fbcon.c               999 if (!fontname[0] || !(font = find_font(fontname)))
  drivers/video/fbdev/core/fbcon.c              1000 font = get_default_font(info->var.xres,
  drivers/video/fbdev/core/fbcon.c              1078 if (!fontname[0] || !(font = find_font(fontname)))
  drivers/video/fbdev/core/fbcon.c              1079 font = get_default_font(info->var.xres,
    * Use 256, cleaned up by [4/5];

  drivers/video/fbdev/core/fbcon.c              2548 else if (!(f = find_font(name)))
  drivers/video/fbdev/core/fbcon.c              2546 f = get_default_font(info->var.xres, info->var.yres,
    * Uses 256 but no easy fix. I'll clean this up after making
      fbcon_do_set_font() pass a `font_desc` as parameter;

  drivers/firmware/efi/earlycon.c               234 font = get_default_font(xres, yres, -1, -1);
    * Does not care about charcount.

Thank you!
Peilin Ye

 drivers/video/console/sticore.c  | 10 +++++-----
 drivers/video/fbdev/atafb.c      |  8 --------
 drivers/video/fbdev/core/fbcon.c |  5 ++---
 include/linux/font.h             |  3 ++-
 lib/fonts/font_10x18.c           |  1 +
 lib/fonts/font_6x10.c            |  1 +
 lib/fonts/font_6x11.c            |  1 +
 lib/fonts/font_6x8.c             |  1 +
 lib/fonts/font_7x14.c            |  1 +
 lib/fonts/font_8x16.c            |  1 +
 lib/fonts/font_8x8.c             |  1 +
 lib/fonts/font_acorn_8x8.c       |  1 +
 lib/fonts/font_mini_4x6.c        |  1 +
 lib/fonts/font_pearl_8x8.c       |  1 +
 lib/fonts/font_sun12x22.c        |  1 +
 lib/fonts/font_sun8x16.c         |  1 +
 lib/fonts/font_ter16x32.c        |  1 +
 17 files changed, 22 insertions(+), 17 deletions(-)

Comments

Peilin Ye Oct. 27, 2020, 4:50 p.m. UTC | #1
Hi Daniel,

More about the 3 things we've discussed before:

  1. Cleaning up con_font_op():

(drivers/tty/vt/vt.c)
int con_font_op(struct vc_data *vc, struct console_font_op *op)
{
	switch (op->op) {
	case KD_FONT_OP_SET:
		return con_font_set(vc, op);
	case KD_FONT_OP_GET:
		return con_font_get(vc, op);
	case KD_FONT_OP_SET_DEFAULT:
		return con_font_default(vc, op);
	case KD_FONT_OP_COPY:
		return con_font_copy(vc, op);
	}
	return -ENOSYS;
}

On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> I think if we change the conf_font_get/set/default/copy functions to not
> take the *op struct (which is take pretty arbitrarily from one of the
> ioctl), but the parameters each needs directly, that would clean up the
> code a _lot_.

    This is on my TODO list! One day I came up with some idea about
    fbcon.c, so I postponed this a bit...

  2. Removing dummy functions, like sisusbdummycon_font_set():
    
    Turns out, before c396a5bf457f ("console: Expand dummy functions for
    CFI"), they were just some macros:

-#define SISUSBCONDUMMY (void *)sisusbdummycon_dummy
+static int sisusbdummycon_font_set(struct vc_data *vc,
+                                  struct console_font *font,
+                                  unsigned int flags)
+{
+       return 0;
+}

    ...and they had been there for a very long (10+ years) time. Removing
    code like this makes me a bit nervous, and...

On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> This actually does something. tbh I would not be surprises if the
> fb_set utility is the only thing that uses this - with a bit of code
> search we could perhaps confirm this, and delete all the other
> implementations.

    ...you mentioned code search, where & what should we look at, in order
    to confirm it's safe to remove them?

  3. Using `font_desc` in `vc_data`:

    Our plan for the gradual conversion was to use a helper function to
    set font for a vc, but after reviewing the 300-ish occurrence of
    `vc_font`, it seems like code doesn't usually set it as a whole:

(drivers/usb/misc/sisusbvga/sisusb_con.c)
	[...]
	c->vc_font.height = sisusb->current_font_height;
	[...]

    ...that's it! It only cares about the height. There are only 4 or 5
    places in fbcon.c that actually set all fields of `vc_font`, like:

    		vc->vc_font.width = font->width;
		vc->vc_font.height = font->height;
		vc->vc_font.data = (void *)(p->fontdata = font->data);
		vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */

    To make it even more complicated, `p` is a `struct fbcon_display *`,
    containing yet another font data pointer (`fontdata`) that I think
    should be replaced by a `font_desc *`...

    In conclusion, I think it's all about a few hard problems in fbcon.c.
    I'll keep trying and see how it goes.
    
Thank you,
Peilin Ye
Daniel Vetter Oct. 27, 2020, 6:36 p.m. UTC | #2
On Tue, Oct 27, 2020 at 5:50 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
>

> Hi Daniel,

>

> More about the 3 things we've discussed before:

>

>   1. Cleaning up con_font_op():

>

> (drivers/tty/vt/vt.c)

> int con_font_op(struct vc_data *vc, struct console_font_op *op)

> {

>         switch (op->op) {

>         case KD_FONT_OP_SET:

>                 return con_font_set(vc, op);

>         case KD_FONT_OP_GET:

>                 return con_font_get(vc, op);

>         case KD_FONT_OP_SET_DEFAULT:

>                 return con_font_default(vc, op);

>         case KD_FONT_OP_COPY:

>                 return con_font_copy(vc, op);

>         }

>         return -ENOSYS;

> }

>

> On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:

> > I think if we change the conf_font_get/set/default/copy functions to not

> > take the *op struct (which is take pretty arbitrarily from one of the

> > ioctl), but the parameters each needs directly, that would clean up the

> > code a _lot_.

>

>     This is on my TODO list! One day I came up with some idea about

>     fbcon.c, so I postponed this a bit...

>

>   2. Removing dummy functions, like sisusbdummycon_font_set():

>

>     Turns out, before c396a5bf457f ("console: Expand dummy functions for

>     CFI"), they were just some macros:

>

> -#define SISUSBCONDUMMY (void *)sisusbdummycon_dummy

> +static int sisusbdummycon_font_set(struct vc_data *vc,

> +                                  struct console_font *font,

> +                                  unsigned int flags)

> +{

> +       return 0;

> +}

>

>     ...and they had been there for a very long (10+ years) time. Removing

>     code like this makes me a bit nervous, and...

>

> On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:

> > This actually does something. tbh I would not be surprises if the

> > fb_set utility is the only thing that uses this - with a bit of code

> > search we could perhaps confirm this, and delete all the other

> > implementations.

>

>     ...you mentioned code search, where & what should we look at, in order

>     to confirm it's safe to remove them?


Way back there was google's code search, which was awesome. Now I just
put the structure name/ioctl #define/number into
google/bing/duckduckgo and see if anything turns up. Plus check how
it's used in fb tools (although I just recently learned that fb-test
pretty much disappeared from the internet, very hard to find the
original).

If you're unsure, we can merge a patch, then wait about 1 year for any
users to show up with problems. If that's not the case, assume they're
all gone, or it was never used and just implemented because it was
copied from somewhere else, or "just in case". There's lots of dead
uapi around.

>   3. Using `font_desc` in `vc_data`:

>

>     Our plan for the gradual conversion was to use a helper function to

>     set font for a vc, but after reviewing the 300-ish occurrence of

>     `vc_font`, it seems like code doesn't usually set it as a whole:

>

> (drivers/usb/misc/sisusbvga/sisusb_con.c)

>         [...]

>         c->vc_font.height = sisusb->current_font_height;

>         [...]

>

>     ...that's it! It only cares about the height. There are only 4 or 5

>     places in fbcon.c that actually set all fields of `vc_font`, like:

>

>                 vc->vc_font.width = font->width;

>                 vc->vc_font.height = font->height;

>                 vc->vc_font.data = (void *)(p->fontdata = font->data);

>                 vc->vc_font.charcount = 256; /* FIXME  Need to support more fonts */

>

>     To make it even more complicated, `p` is a `struct fbcon_display *`,

>     containing yet another font data pointer (`fontdata`) that I think

>     should be replaced by a `font_desc *`...

>

>     In conclusion, I think it's all about a few hard problems in fbcon.c.

>     I'll keep trying and see how it goes.


Yeah fbcon.c is pretty good horrors unfortunately :-/
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Daniel Vetter Oct. 27, 2020, 6:44 p.m. UTC | #3
On Tue, Oct 27, 2020 at 12:31:08PM -0400, Peilin Ye wrote:
> Remove 6 unused extern variables to reduce confusion. It is worth
> mentioning that lib/fonts/font_8x8.c and lib/fonts/font_8x16.c also
> declare `fontdata_8x8` and `fontdata_8x16` respectively, and this file
> has nothing to do with them.
> 
> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>

This was unused ever since this driver was merged into 2.1.67 (I looked at
historical linux git trees quickly). Save to delete I'd say, probably just
copypasted from some outdated driver template that was even older.

Applied to drm-misc-next.
-Daniel
> ---
> $ # Build-tested (Ubuntu 20.04)
> $ sudo apt install gcc-m68k-linux-gnu
> $ cp arch/m68k/configs/atari_defconfig .config
> $ make ARCH=m68k menuconfig
> $ make ARCH=m68k CROSS_COMPILE=m68k-linux-gnu- -j`nproc` all
> 
>  drivers/video/fbdev/atafb.c | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
> index f253daa05d9d..e3812a8ff55a 100644
> --- a/drivers/video/fbdev/atafb.c
> +++ b/drivers/video/fbdev/atafb.c
> @@ -240,14 +240,6 @@ static int *MV300_reg = MV300_reg_8bit;
>  
>  static int inverse;
>  
> -extern int fontheight_8x8;
> -extern int fontwidth_8x8;
> -extern unsigned char fontdata_8x8[];
> -
> -extern int fontheight_8x16;
> -extern int fontwidth_8x16;
> -extern unsigned char fontdata_8x16[];
> -
>  /*
>   * struct fb_ops {
>   *	* open/release and usage marking
> -- 
> 2.25.1
>
Peilin Ye Oct. 28, 2020, 5:34 a.m. UTC | #4
On Tue, Oct 27, 2020 at 07:36:54PM +0100, Daniel Vetter wrote:
> On Tue, Oct 27, 2020 at 5:50 PM Peilin Ye <yepeilin.cs@gmail.com> wrote:
> >     ...you mentioned code search, where & what should we look at, in order
> >     to confirm it's safe to remove them?
> 
> Way back there was google's code search, which was awesome. Now I just
> put the structure name/ioctl #define/number into
> google/bing/duckduckgo and see if anything turns up. Plus check how
> it's used in fb tools (although I just recently learned that fb-test
> pretty much disappeared from the internet, very hard to find the
> original).
> 
> If you're unsure, we can merge a patch, then wait about 1 year for any
> users to show up with problems. If that's not the case, assume they're
> all gone, or it was never used and just implemented because it was
> copied from somewhere else, or "just in case". There's lots of dead
> uapi around.

I see, it will be my next thing to do. Hopefully this will remove a lot
of console_font occurrences.

Peilin