Message ID | cover.1603788511.git.yepeilin.cs@gmail.com |
---|---|
Headers | show |
Series | Preparation work for using font_desc in vc_data | expand |
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
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
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 >
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