From nobody Wed Jan 5 16:04:16 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DA2421934709 for ; Wed, 5 Jan 2022 16:04:54 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTZ7V5F5Rz4lLW; Wed, 5 Jan 2022 16:04:54 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-wr1-x42f.google.com with SMTP id h23so1091401wrc.1; Wed, 05 Jan 2022 08:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vwZv3RSBBE1JEMfutqFrjnFMKT2dGo00S8IZ2qPgv70=; b=eVXxKPJjgDFJVATEYa7GqkFFpuFAoAvAbsrhAy5KeBNWdzWma2khydWBK9VS61ZMD1 I4wrc07zBCbG2lGCkFRmGvbLRrhLYVzXt3NT6nWebfk3tPoLsk92tbY+WfWsKzTz5+Uk 3bgVFfF8r3ZxuJCDrUvlSi+FSHXPWNSNtx5wrDHMn9/UNMso6MComBFcUo/TrxviS4sQ UdHMvZgo8TKGzOBzYoXXiKJAOe0c7Djb/YNrk0rBt/Wkk0q/I9JKuyz1Aduan1R9BFDT ahVJI+WC5J6iiFlRl0M5K0h+qWxxhLo65a5hq89cMfW8nE6NyF2JdJZh6qdop3muj4Fy 12xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vwZv3RSBBE1JEMfutqFrjnFMKT2dGo00S8IZ2qPgv70=; b=Vg777HzfawZvRy0OGUuOMhIVCCPj6LcjUsjVfaCkHPzTWGBtiTUWmDIcc2TaQwPzgG gA47Fwi8hTa6BP1esfIsXhPPLvJflVdpDiIi3j4H8u/SjOodKgg7GxIl6bIu8dV3Jxhx v1JQJK587dWsakLAk81OZQiSYkYVkHBk/Dz1xx07/dpmtDnSbvLbgQRX8c0giWksFQRd MYaYFlRyo79Dza2AZbyyzsyjfw/yLcMDGrOQ2Kk2oXUz1aObn+J48mTpN8cCnE+S/0eo ZYM78q8GTIcNYsuVfuzDTPLffWWMnl8ZNLwEXEJqQmhwRqqDbZhs+IgJiU0MGAazXd0I mhtQ== X-Gm-Message-State: AOAM532NkkjZUYO1jx47xWZf8PXHKncffmjOfg4Lw7Bq4Z/3ElHe2yxC XdmuBCC4EZkOY8ZsQW15lz6rZRncbhYprrylQ2sj5UGTyCYd2w== X-Google-Smtp-Source: ABdhPJx43ETQfWiwfxwitT8ireK8bOcv9Bas/Zgm7CTCBtSy3hhiq7KAtJ/yv/QJaRhv03oKvzPuA7Jzy12gAhWL3rM= X-Received: by 2002:a5d:6d05:: with SMTP id e5mr46884422wrq.46.1641398692951; Wed, 05 Jan 2022 08:04:52 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Mehmet Erol Sanliturk Date: Wed, 5 Jan 2022 19:04:16 +0300 Message-ID: Subject: Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann Cc: Warner Losh , Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000000738b405d4d7ea97" X-Rspamd-Queue-Id: 4JTZ7V5F5Rz4lLW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000000738b405d4d7ea97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not a part of this discussion , and the problem is not affecting me . But ... Such situations really are causing significant pain in my soul . Why ? ( I am a graduate of Mathematics , In our work every claim requires a PROOF , not words of a BIG one , whether she/he is me or any other one . ) I graduated in 1974 and started as a "System Analyst and Designer" job in Hacettepe University ( Ankara , Turkey ) . In our school , the computer was IBM System 360 with 64 KILO bytes . In Hacettepe Data Processing Center , the computer was a Burroughs B3500 with 128 KILO bytes ( called in that system as 256 KILO digits ) . https://en.wikipedia.org/wiki/Burroughs_Medium_Systems Burroughs Medium Systems https://en.wikipedia.org/wiki/Burroughs_MCP Burroughs MCP I front of its console ( Commands may be differently written ) : --- stop n <---- Number of multi-tasked job --- . --- . --- . --- start n <---- Number of multi-tasked job --- . --- . --- . --- set priority n as m ... A company of Hacettepe University was using the computer during nights . When they were starting around 18:00 : --- load / into tape in { cluster unit of } n ( 1 , 2 , 3 ,or 4 ) --- remove / <----- All of the contents ( written as / ) of the 100 MEGA bytes Hard disk larger than a caravan type automobile . --- load tape from { cluster unit of } n ( 1 , 2 , 3 ,or 4 ) A short time later , ALL of the MCP ( Master Control Program ) and data was loaded into the hard disk and ALL of the possible work began . Around 1979 , a new mainframe arrived to Beytepe campus of Hacettepe : Burroughs B6700 with 2 ( TWO ) MEGA bytes memory . https://en.wikipedia.org/wiki/Category:Burroughs_mainframe_computers Category:Burroughs mainframe computers https://en.wikipedia.org/wiki/Category:High-level_language_computer_archite= cture Category:High-level language computer architecture https://en.wikipedia.org/wiki/Burroughs_large_systems Burroughs large systems Around 1980 years , one engineer working for a large USA company made a remark , approximately , : "... Optimization of a very large Fortran program such as 2000 lines is a very difficult task . ... " Some of my mathematical analysis programs much larger than 2000 lines were developed and executed on this computer . It is not easy to develop such a large program without possible run time error(s) . Burroughs B6700 computer ( multi-tasked ) was using "print spooling" . In output of program , after banner about user name and some other information about the job , was listing a stack trace ( approximately in the following structure , the listing is not the exact reproduction ) : Run time error : n has occurred in line : m in routine : name called by routine : name from line : k called by routine : name from line : k . . . called by main : name from line : k Now the year is 2022 . You know what is the level of maturity or usability or other features of existing systems . The cpu speed is around 3 GIGA Herz . The memory sizes are { 4 or 8 or 16 or 32 or 64 or 128 or 256 ... ) GIGA Bytes ... The job done is ... : I do not know anything except fancy or fantastic screen paints or other useless things excluding facilities like the examples given above ... Please NEVER think that I am blaming our very valuable contributors . Contrary to such a disgusting behavior I am very indebted to them for their efforts ( means using their a part of very holy life time for the benefit of humanity ) . I know the difficulty of working in such a time : When it is understood that a pandemic has started , my official medical doctor called me to say : "Never go outside ! It is very dangerous for you ... " . Since at the beginning of 2020 February I am in isolation . The other people are not better than me with respect to their jobs , dangers for their families and themselves . At that , we need ways to maximize productivity of our contributors and users of FreeBSD by minimizing waste of their time ( ... ) and resources . How ? This is a different story outside of this thread . I am very sorry to waste your time . With my best wishes for your future and your work . Mehmet Erol Sanliturk On Wed, Jan 5, 2022 at 3:17 PM Stefan Blachmann wrote: > On 1/4/22, Warner Losh wrote: > > 15 or 20 years [...] > > main reason laptops stopped suspending in the early 2000s... [...] > > And the INT xx interface is unavailable on amd64 after we > > enter long mode > > First, you mentioned a hacking session in the "early 2000s". > This makes me wonder whether you might mistake some other thing from > the distance of time, as UEFI was no real thing until ~2010, and was > never a thing on platforms other than amd64 also. Suspend/resume on > FreeBSD only appeared much later, too. > > Second, there is kernel functionality to call real mode interrupt > handlers from long mode, which manage switching to real mode and back. > Just an example, these are being used by vt (via vesa.ko) to switch vesa > modes. > > So I do not see why this real mode access infrastructure could not > also be used to make a call to C000:(PCI PROM Programming interface > code offset), or the respective segment address where the actual VGA > BIOS is, to have it initialize the int 10h interface handler, if a > hybrid/dual graphics card BIOS is present. > I think a single function "InitializeVGABIOSifpresent" to enable > access to VGA/VESA BIOS functionality might actually be fairly easy to > implement. > Furthermore, there is no need at all to access hardware specific stuff > like you mentioned, as the necessary functionality is completely > covered by the int 10h interface. > > Imho it could be worth to allocate a small part of the sponsoring > budget to put a bounty to motivate people (including possibly me) to > implement these improvements regarding suspend/resume and enhanced sc > and vt usability. > > > > On 1/4/22, Warner Losh wrote: > > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > > wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > >> UEFI GOP seems to have the necessary functionalities > >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work > >> required would be limited (restore mode and redraw screen from > >> buffer). > >> > > > > UEFI GOP isn't available after we start the kernel, so this is a > > non-starter. > > It works great in the boot loader, but not so good after we boot. It > could > > work > > for S3 sleep to disk where we actually reboot to restore the machine > state, > > but we don't have sleep to disk today :( > > > > > >> With non-UEFI or old UGA UEFI implementations possibly one could use > >> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set up GP= U and > >> the int 10h interface, and then set previously used mode+redraw. > >> BTW, doing that also could both enable vt(4) to change > >> modes/resolutions and using sc on UEFI computers. > >> > > > > Ah, if only things were really that simple... I tried variations on th= at > > hack years ago when suspending broke due to video. And it > > works for some machines, but not others, was the quick assessment > > I made. And the INT xx interface is unavailable on amd64 after we > > enter long mode (I tried this out on my then-current FreeBSD laptop > > which was 32 bit only, so 15 years ago?). > > > > Warner > > > > > >> But I think you are right, there are probably not too many users who > >> would make use of that. > >> > >> > >> On 1/4/22, Warner Losh wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > wrote: > >> > > >> >> Implementing S3 suspend/resume was a sponsored project itself. > >> >> However, it still does only work when at xorg graphics mode, which > >> >> already was topic in this thread. > >> >> When using it from console, no matter sc or vt, it still hangs with > >> >> dark screen and unresponsive keyboard. > >> >> Could finishing the suspend/resume work be sponsored, so that it al= so > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > stuff knows about... IIRC, it only knows about it because it put the > >> > graphics into a known state... it's the main reason laptops stopped > >> > suspending in the early 2000s... it looks to be a lot of work for a > >> > relatively rare use case... > >> > > >> > Warner > >> > > >> > > >> >> On 12/30/21, Joseph Mingrone wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK > >> >> >> wrote: > >> >> >>> I've ideas about enhancing the routing architecture. Is it > >> >> >>> possible > >> >> >>> to > >> >> >>> add to wiki? > >> >> > > >> >> >> Certainly. Please do. > >> >> > > >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI > >> >> > > >> >> > >> >> > >> > > >> > > > > --0000000000000738b405d4d7ea97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am not a part of this disc= ussion , and the problem is not affecting me .
But ... Such = situations really are causing significant=C2=A0 pain in my soul .

Why ?

( I am a= graduate of Mathematics , In our work every claim requires a PROOF , not
words of a BIG one , whether she/he is me or any other one . = )


I graduated in 197= 4 and started as a "System Analyst and Designer" job in
Hacettepe University ( Ankara , Turkey ) . In our school , the c= omputer was
IBM System 360 with 64 KILO bytes . In Hace= ttepe Data Processing Center , the computer
was a Burroughs = B3500 with=C2=A0 128 KILO bytes ( called in that system as 256 KILO digits = ) .




https://en.wikipedia.org/wiki/Burroughs_Medium_Systems<= /div>
Burroughs Medium Systems

Burroughs MCP




I front of its console ( Commands may be differently written ) :

--- stop=C2=A0 n=C2=A0 <---- Number of m= ulti-tasked job
--- .
--- .
--- .
--- start=C2=A0 n=C2=A0 = <---- Number of multi-tasked job
--- .
--- .
--- .
--- = set priority n as=C2=A0 m
=C2=A0...

<= /div>
A company of Hacettepe University was using the computer dur= ing nights .
When they were starting around=C2=A0 18:00 :


--- load=C2=A0 /=C2=A0= into tape in { cluster unit of }=C2=A0 n=C2=A0=C2=A0 ( 1 , 2 , 3 ,or 4 )


--- remove=C2=A0 = /=C2=A0=C2=A0=C2=A0 <----- All of the contents ( written as=C2=A0 /=C2= =A0 ) of the=C2=A0 100 MEGA bytes
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Hard disk larger than a caravan type automobile .
=

--- load tape from { cluster unit of }=C2=A0 = n=C2=A0=C2=A0 ( 1 , 2 , 3 ,or 4 )

=C2= =A0=C2=A0=C2=A0 A short time later , ALL of the MCP ( Master Control Progra= m ) and data
=C2=A0=C2=A0=C2=A0 was loaded into the hard dis= k and ALL of the possible work began .

= Around=C2=A0 1979 , a new mainframe arrived to Beytepe campus of Hacettepe = :

Burroughs B6700=C2=A0 with 2 ( TWO )= =C2=A0 MEGA bytes memory .




https://en.wikipedia.o= rg/wiki/Category:Burroughs_mainframe_computers
Category:Burroughs = mainframe computers


https://en.wikipedia= .org/wiki/Category:High-level_language_computer_architecture
Categor= y:High-level language computer architecture

<= /div>

https://en.wikipedia.org/wiki/Burroughs_large_sys= tems
Burroughs large systems



Around=C2=A0 1980 years= , one engineer working for a large USA company made a
= remark , approximately , :=C2=A0 "... Optimization of a very large For= tran program such as
2000 lines is a very difficult task . .= .. "

Some of my mathematical = analysis programs much larger than 2000 lines were developed
and executed on this computer .

It is n= ot easy to develop such a large program=C2=A0 without possible run time err= or(s) .

Burroughs B6700 computer ( multi= -tasked ) was using "print spooling" .
In output o= f program , after banner about user name and some other information
about the job , was listing a stack trace ( approximately in t= he following structure ,
the listing is not the exact reprod= uction ) :

Run time error : n
has occurred in line : m=C2=A0 in routine :=C2=A0 name

called by routine :=C2=A0=C2=A0 name =C2=A0 =C2=A0= from line :=C2=A0=C2=A0 k
called by routine :=C2= =A0=C2=A0 name =C2=A0 =C2=A0 from line :=C2=A0=C2=A0 k

= =C2=A0 .
=C2=A0 .
=C2=A0 .
called by main :=C2=A0=C2=A0 name =C2=A0 from li= ne :=C2=A0=C2=A0 k


Now t= he year is 2022 . You know what is the level of maturity or usability or
other features of existing systems . The cpu speed is aro= und 3 GIGA Herz .
The memory sizes are {=C2=A0 4 or 8 or 16 = or 32 or 64 or 128 or 256 ... ) GIGA Bytes ...
The job d= one is ... : I do not know anything except=C2=A0 fancy or fantastic screen = paints or other useless things excluding facilities like the examples given= above ...



=
Please=C2=A0 NEVER think that I am blaming our very valuabl= e contributors . Contrary to
such a disgusting behavior=C2= =A0 I=C2=A0 am very indebted to them for their efforts ( means
using their a part of very holy life time for the benefit of humani= ty ) .

I know the difficulty of working = in such a time : When it is understood that a pandemic
has s= tarted , my official medical doctor called me to say :

<= /div>
"Never go outside !=C2=A0=C2=A0 It is very dangerous fo= r you ... " .

Since at the beg= inning of 2020 February I am in isolation .
The other p= eople are not better than me with respect to their jobs ,
dangers for their families and themselves .



At that , we need ways= =C2=A0 to maximize=C2=A0 productivity of our contributors and users
of FreeBSD=C2=A0 by minimizing=C2=A0 waste of their time ( ... ) an= d resources .

How ?
This is a different story outside of this thread .


I am very sorry to wast= e your time .

With my best wishes for = your future and your work .




Mehmet Erol Sanliturk



=

On Wed, Jan 5, 2022 at 3:17 PM Stefan Blachmann <sblachmann@gmail.com> wrote:
On 1/4/22, Warner Losh <<= a href=3D"mailto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com> w= rote:
> 15 or 20 years [...]
> main reason laptops stopped suspending in the early 2000s... [...]
> And the INT xx interface is unavailable on amd64 after we
> enter long mode

First, you mentioned a hacking session in the "early 2000s".
This makes me wonder whether you might mistake some other thing from
the distance of time, as UEFI was no real thing until ~2010, and was
never a thing on platforms other than amd64 also. Suspend/resume on
FreeBSD only appeared much later, too.

Second, there is kernel functionality to call real mode interrupt
handlers from long mode, which manage switching to real mode and back.
Just an example, these are being used by vt (via vesa.ko) to switch vesa mo= des.

So I do not see why this real mode access infrastructure could not
also be used to make a call to C000:(PCI PROM Programming interface
code offset), or the respective segment address where the actual VGA
BIOS is, to have it initialize the int 10h interface handler, if a
hybrid/dual graphics card BIOS is present.
I think a single function "InitializeVGABIOSifpresent" to enable<= br> access to VGA/VESA BIOS functionality might actually be fairly easy to
implement.
Furthermore, there is no need at all to access hardware specific stuff
like you mentioned, as the necessary functionality is completely
covered by the int 10h interface.

Imho it could be worth to allocate a small part of the sponsoring
budget to put a bounty to motivate people (including possibly me) to
implement these improvements regarding suspend/resume and enhanced sc
and vt usability.



On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
> On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann <sblachmann@gmail.com>
> wrote:
>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>>
>> UEFI GOP seems to have the necessary functionalities
>> (https://wiki.osdev.org/GOP#Get_the_Curren= t_Mode) so I guess the work
>> required would be limited (restore mode and redraw screen from
>> buffer).
>>
>
> UEFI GOP isn't available after we start the kernel, so this is a > non-starter.
> It works great in the boot loader, but not so good after we boot. It c= ould
> work
> for S3 sleep to disk where we actually reboot to restore the machine s= tate,
> but we don't have sleep to disk today :(
>
>
>> With non-UEFI or old UGA UEFI implementations possibly one could u= se
>> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set u= p GPU and
>> the int 10h interface, and then set previously used mode+redraw. >> BTW, doing that also could both enable vt(4) to change
>> modes/resolutions and using sc on UEFI computers.
>>
>
> Ah, if only things were really that simple...=C2=A0 I tried variations= on that
> hack years ago when suspending broke due to video. And it
> works for some machines, but not others, was the quick assessment
> I made. And the INT xx interface is unavailable on amd64 after we
> enter long mode (I tried this out on my then-current FreeBSD laptop > which was 32 bit only, so 15 years ago?).
>
> Warner
>
>
>> But I think you are right, there are probably not too many users w= ho
>> would make use of that.
>>
>>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann <sblachmann@gmail.com>= ;
>> > wrote:
>> >
>> >> Implementing S3 suspend/resume was a sponsored project it= self.
>> >> However, it still does only work when at xorg graphics mo= de, which
>> >> already was topic in this thread.
>> >> When using it from console, no matter sc or vt, it still = hangs with
>> >> dark screen and unresponsive keyboard.
>> >> Could finishing the suspend/resume work be sponsored, so = that it also
>> >> works on console-only computers?
>> >>
>> >
>> > Not without loading the xorg graphics stuff... graphics chips= from the
>> last
>> > 15 or 20 years have lots of chip specific state that only the= graphics
>> > stuff knows about... IIRC, it only knows about it because it = put the
>> > graphics into a known state... it's the main reason lapto= ps stopped
>> > suspending in the early 2000s... it looks to be a lot of work= for a
>> > relatively rare use case...
>> >
>> > Warner
>> >
>> >
>> >> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wrote:
>> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm= @FreeBSD.org>
>> >> > wrote:
>> >> >
>> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK &l= t;ozkan.kirik@gm= ail.com>
>> >> >> wrote:
>> >> >>> I've ideas about enhancing the routing a= rchitecture. Is it
>> >> >>> possible
>> >> >>> to
>> >> >>> add to wiki?
>> >> >
>> >> >> Certainly.=C2=A0 Please do.
>> >> >
>> >> > The link again is https://wiki.free= bsd.org/2021FoundationCFI
>> >> >
>> >>
>> >>
>> >
>>
>

--0000000000000738b405d4d7ea97--