Re: Reasons for keeping sc(4) and libvgl ?

On Tue, Jun 21, 2022 at 11:46 PM Eugene Grosbein <eugen@grosbein.net> wrote:

> 22.06.2022 12:34, Warner Losh wrote:
>
> > On Tue, Jun 21, 2022, 10:59 PM Steve Kargl <
> sgk@troutmask.apl.washington.edu <mailto:sgk@troutmask.apl.washington.edu>>
> wrote:
> >
> >     On Tue, Jun 21, 2022 at 10:55:01PM -0600, Warner Losh wrote:
> >     > On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann <
> sblachmann@gmail.com <mailto:sblachmann@gmail.com>> wrote:
> >     >
> >     > > I would kindly ask to stop pushing for removal of sc.
> >     > >
> >     >
> >     > It will die soon enough if it doesn't become giant locked soon...
> >     >
> >     > Warner
> >     >
> >
> >     Are you deleting vt, too?
> >
> >
> > The project likely has resources to remove giant from only one console
> driver. That will almost certainly be vt.
>
> Then sc(4) should stay giant-locked until vt(4) implements all features
> called-for sc.
> After all, sc is not network nor I/O "hot path".
>

Giant is being removed entirely, and with it all straggler drivers that
aren't converted by the removal date.
There's no fixed date for this, at the present time, but I'm about to
commit changes that make it impossible
for new code to reference Giant. Having Giant, at all, causes slow downs
elsewhere in the system, which
is why we're pushing to remove it entirely. sc(4) has lots of giant use,
and is intertwingled with atkbdc, atkbd
and ms in ways that are tricky to unwind (though some work to unwind ms has
been committed).

"All" features won't be a gating factor, unfortunately, unless somebody
steps up and (a) does them
or (b) actively funds the work. vt(4) is complete enough that straggler
issues won't gate a future sc(4)
removal when Giant goes away. Especially since many of the issues are on
hard to obtain platforms
and/or cards that aren't entirely mainstream. In an ideal world, we'd not
have to make such choices,
but the project must and it's better to be honest about it than to give
people false hope.

Warner