Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jun 2022 12:45:27 +0700
From:      Eugene Grosbein <eugen@grosbein.net>
To:        Warner Losh <imp@bsdimp.com>, Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc:        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:  <6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14@grosbein.net>
In-Reply-To: <CANCZdfraihrmoHsu85aFWUT3zwTO%2B-x_Jbcdk0f%2Bxrr7kMxckg@mail.gmail.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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".



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6b7997d6-f8ed-c4e4-91eb-da9b20eb0a14>