Date: Thu, 23 Jun 2022 09:26:43 -0600 From: Warner Losh <imp@bsdimp.com> To: Eugene Grosbein <eugen@grosbein.net> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu>, Stefan Blachmann <sblachmann@gmail.com>, Emmanuel Vadot <manu@bidouilliste.com>, Ed Maste <emaste@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Reasons for keeping sc(4) and libvgl ? Message-ID: <CANCZdfq1mGynidmm%2BPniYdmb5Tu-fh6N6C8zm8oKwB5mnoj5yA@mail.gmail.com> In-Reply-To: <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net> References: <20211126160454.3eb827365a02103169ab9adc@bidouilliste.com> <20220621201924.e9b96876c947140ac1f3b7a4@bidouilliste.com> <3d09c86a-9840-f8bf-4725-8098d958a01d@plan-b.pwste.edu.pl> <202206211901.25LJ1uBd067376@critter.freebsd.dk> <CAPyFy2Ca83X042jc5QE-g=eHAfnukHScrTSyaLRi4UxeTBasJQ@mail.gmail.com> <20220622044923.6e2fac81c1e8205872d9de11@bidouilliste.com> <CACc-My0q-Ods_O-TDru=tEwjSOaUJZZd=ZTzD46nY1gjGYO_VA@mail.gmail.com> <CANCZdfoRCB5RuszKWTQazRuseRnapVqMTANnQTR0b61AHw54aQ@mail.gmail.com> <YrKhlZnlF%2ByxZd9X@troutmask.apl.washington.edu> <CANCZdfraihrmoHsu85aFWUT3zwTO%2B-x_Jbcdk0f%2Bxrr7kMxckg@mail.gmail.com> <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000701be205e21f1552 Content-Type: text/plain; charset="UTF-8" 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 --000000000000701be205e21f1552 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 21, 2022 at 11:46 PM Euge= ne Grosbein <<a href=3D"mailto:eugen@grosbein.net">eugen@grosbein.net</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">22.= 06.2022 12:34, Warner Losh wrote:<br> <br> > On Tue, Jun 21, 2022, 10:59 PM Steve Kargl <<a href=3D"mailto:sgk@t= routmask.apl.washington.edu" target=3D"_blank">sgk@troutmask.apl.washington= .edu</a> <mailto:<a href=3D"mailto:sgk@troutmask.apl.washington.edu" tar= get=3D"_blank">sgk@troutmask.apl.washington.edu</a>>> wrote:<br> > <br> >=C2=A0 =C2=A0 =C2=A0On Tue, Jun 21, 2022 at 10:55:01PM -0600, Warner Lo= sh wrote:<br> >=C2=A0 =C2=A0 =C2=A0> On Tue, Jun 21, 2022, 9:47 PM Stefan Blachmann= <<a href=3D"mailto:sblachmann@gmail.com" target=3D"_blank">sblachmann@g= mail.com</a> <mailto:<a href=3D"mailto:sblachmann@gmail.com" target=3D"_= blank">sblachmann@gmail.com</a>>> wrote:<br> >=C2=A0 =C2=A0 =C2=A0><br> >=C2=A0 =C2=A0 =C2=A0> > I would kindly ask to stop pushing for re= moval of sc.<br> >=C2=A0 =C2=A0 =C2=A0> ><br> >=C2=A0 =C2=A0 =C2=A0><br> >=C2=A0 =C2=A0 =C2=A0> It will die soon enough if it doesn't beco= me giant locked soon...<br> >=C2=A0 =C2=A0 =C2=A0><br> >=C2=A0 =C2=A0 =C2=A0> Warner<br> >=C2=A0 =C2=A0 =C2=A0><br> > <br> >=C2=A0 =C2=A0 =C2=A0Are you deleting vt, too?<br> > <br> > <br> > The project likely has resources to remove giant from only one console= driver. That will almost certainly be vt.<br> <br> Then sc(4) should stay giant-locked until vt(4) implements all features cal= led-for sc.<br> After all, sc is not network nor I/O "hot path".<br></blockquote>= <div><br></div><div>Giant is being removed entirely, and with it all stragg= ler drivers that aren't converted by the removal date.</div><div>There&= #39;s no fixed date for this, at the present time, but I'm about to com= mit changes that make it impossible</div><div>for new code to reference Gia= nt. Having Giant, at all, causes slow downs elsewhere in the system, which<= /div><div>is why we're pushing to remove it entirely. sc(4) has lots of= giant use, and is intertwingled with atkbdc, atkbd</div><div>and ms in way= s that are tricky to unwind (though some work to unwind ms has been committ= ed).</div><div><br></div><div>"All" features won't be a gatin= g factor, unfortunately, unless somebody steps up and (a) does them</div><d= iv>or (b) actively funds the work. vt(4) is complete enough that straggler = issues won't gate a future sc(4)</div><div>removal when Giant goes away= . Especially since many of the issues are on hard to obtain platforms</div>= <div>and/or cards that aren't entirely mainstream. In an ideal world, w= e'd not have to make such choices,</div><div>but the project must and i= t's better to be honest about it than to give people false hope.</div><= div><br></div><div>Warner</div></div></div> --000000000000701be205e21f1552--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfq1mGynidmm%2BPniYdmb5Tu-fh6N6C8zm8oKwB5mnoj5yA>